DE69909829T2

DE69909829T2 - Vielfadenprozessor für faden-softwareanwendungen

Info

Publication number: DE69909829T2
Application number: DE69909829T
Authority: DE
Inventors: Marc Tremblay; N. William JOY
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1998-12-03
Filing date: 1999-12-03
Publication date: 2004-05-27
Anticipated expiration: 2019-12-04
Also published as: WO2000033185A2; US20050010743A1; US20060282650A1; US7042466B1; DE69909829D1; WO2000033185A3; EP1137984B1; US20010042188A1; US6718457B2; EP1137984A2

Description

TECHNISCHER BEREICH
Die vorliegende Erfindung betrifft eine Prozessorarchitektur. Die vorliegende Erfindung betrifft insbesondere eine Ein-Chip-Prozessorarchitektur mit Strukturen für Multiple-Thread-Betrieb.
TECHNISCHER HINTERGRUND
Für verschiedene Verarbeitungsanwendungen kann ein automatisiertes System mehrere Events oder Prozesse gleichzeitig handhaben. Ein einzelner Prozess wird als Steuerfaden oder "Thread" bezeichnet und ist die Grundeinheit des Betriebs einer unabhängigen dynamischen Aktion innerhalb des Systems. Ein Programm hat wenigstens einen Thread. Ein System, das parallele Operationen durchführt, hat gewöhnlich viele Threads, von denen einige vorübergehend und andere andauernd sind. Systeme, die auf mehrere Prozessoren verteilt ausgeführt werden, ermöglichen wahrhaft parallele Threads. Einprozessorsysteme können nur illusorische parallele Threads haben, die gewöhnlich durch eine Prozessorausführung mit Zeitscheiben erzielt werden können, die von einer Mehrzahl von Threads gemeinsam genutzt werden.
Zwei Beispiele für Multiple-Thread-Prozessoren sind im US-Patent Nr. 5,742,782 mit dem Titel "Processing apparatus for executing a plurality of VLIW threads in parallel" (Motohisa Ito et al.) und im US-Patent Nr. 5,574,939 mit dem Titel "Multiprocessor coupling system with integrated compile and run time scheduling parallelism" (Stephen W. Keckler, et al.) beschrieben. Ito et al. erzielen Multi-Thread-Ausführung durch Verwenden einer Mehrzahl von Befehlsdecoderteilen und einer entsprechenden Mehrzahl von Registerteilen, um Ausführungs-Threads zu organisieren und Ergebnisse für die jeweiligen Threads zu speichern. Die Befehlsdecoderteile bilden die Befehlsthreads zu langen Instruktionsworten (VLIW) und senden die langen Instruktionsworte durch einen einzigen Satz von Befehlsschedulerteilen und Ausführungsteilen, die unter den Threads zeitlich aufgeteilt sind. Keckler et al. führen einen Multi-Thread-Betrieb mit Hilfe von parallelen Prozessoren durch, die Operationen von einem Instruktionswort parallel ausführen können. Die parallelen Prozessoren werden von Rechenthreads gemeinsam genutzt und können Operationen von verschiedenen Instruktionswörtern unterschiedlicher Rechenthreads verarbeiten, so dass die Ausführung von Threads zwischen den mehreren Prozessoren verschachtelt ist. Ein Nachteil der Systeme von Ito et al. und von Keckler et al. besteht darin, dass nur ein Satz von Ausführungseinheiten von mehreren Threads gemeinsam genutzt wird, so dass die Befehle in mehreren Threads nicht gleichzeitig ausgeführt werden können.
Es wurden insbesondere einige Programmiersprachen entworfen, die Multiple-Threading unterstützen sollen. Eine solche Sprache ist die Programmiersprache Java^TM, die vorteilhafterweise mit einer abstrakten Rechenmaschine ausgeführt wird, der Java Virtual Machine^TM. Eine Java Virtual Machine^TM kann mehrere Ausführungsthreads gleichzeitig unterstützen. Die mehreren Threads führen unabhängig Java-Code aus, der auf Java-Werte und Objekte wirkt, die sich im gemeinsam genutzten Hauptspeicher befinden. Die mehreren Threads können mit mehreren Hardware-Prozessoren entweder durch einen Zeitscheibenbetrieb eines einzelnen Hardware-Prozessors oder einen Zeitscheibenbetrieb vieler Hardware-Prozessoren unterstützt werden. 1990 entwickelten Programmierer bei Sun Microsystems eine universelle Programmiersprache, die schließlich als "die Java^TM Programmiersprache" bekannt wurde. Java^TM, Sun, Sun Microsystems und das Sun Logo sind Warenzeichen oder eingetragene Warenzeichen von Sun Microsystems, Inc. in den Vereinigten Staaten und in anderen Ländern. Alle SPARC-Warenzeichen, einschließlich UltraSPARC I und UltraSPARC II, werden unter Lizenz gebraucht und sind Warenzeichen von SPARC International, Inc. in den Vereinigten Staaten und in anderen Ländern. SPARC-Warenzeichen tragende Produkte basieren auf einer von Sun Microsystems, Inc. entwickelten Architektur.
Java^TM unterstützt die Codierung von Programmen, die, obwohl verzahnt, deterministisches Verhalten zeigen, da sie Techniken und Strukturen zum Synchronisieren der verzahnten Aktivität von Threads beinhaltet. Um Threads zu synchronisieren, verwendet Java^TM Monitore, High-Level-Konstrukte, die nur einen einzigen Thread gleichzeitig zur Ausführung einer von dem Monitor geschützten Code-Region zulassen. Monitore arbeiten mit Sperrungen in Verbindung mit ausführbaren Objekten zum Steuern der Thread-Ausführung.
Ein Thread führt Code aus, indem er eine Folge von Aktionen durchführt. Ein Thread kann den Wert einer Variablen verwenden oder der Variablen einen neuen Wert zuweisen. Wenn zwei oder mehr verzahnte Threads auf eine gemeinsam genutzte Variable wirken, dann können die Aktionen auf der Variablen ein zeitabhängiges Ergebnis erzeugen, eine inhärente Folge der verzahnten Programmierung.
Jeder Thread hat einen Arbeitsspeicher, der Kopien der Werte von Masterkopien von Variablen vom Hauptspeicher speichern kann, den alle Threads gemeinsam nutzen. Ein Thread greift gewöhnlich auf eine Gemeinschaftsvariable zu, indem er eine Sperrung erhält und den Arbeitsspeicher des Threads entleert, wodurch gewährleistet wird, dass danach gemeinsam genutzte Werte vom Gemeinschaftsspeicher auf den Arbeitsspeicher des Threads geladen werden. Durch Freigeben einer Sperrung gewährleistet ein Thread, dass die vom Thread im Arbeitsspeicher geführten Werte zurück auf den Hauptspeicher geschrieben werden.
Mehrere Ausführungsregeln schränken die Reihenfolge ein, in der bestimmte Events auftreten können. So werden beispielsweise von einem Thread durchgeführte Aktionen vollkommen so geordnet, dass für beliebige zwei von einem Thread durchgeführte Aktionen eine Aktion auf die andere folgt. Vom Hauptspeicher für eine beliebige Variable durchgeführte Aktionen werden vollständig so geordnet, dass für beliebige zwei vom Hauptspeicher an derselben Variablen durchgeführte Aktionen eine Aktion auf die andere folgt. Vom Hauptspeicher für eine beliebige Sperrung durchgeführte Aktionen werden vollständig so geordnet, dass für beliebige zwei vom Hauptspeicher an derselben Sperrung durchgeführte Aktionen eine Aktion auf die andere folgt. Auch wird nicht zugelassen, dass eine Aktion auf sich selbst folgt. Threads interagieren nicht direkt miteinander, sondern kommunizieren nur über den gemeinschaftlichen Hauptspeicher.
Auch die Beziehungen zwischen den Aktionen eines Threads und den Hauptspeicheraktionen sind durch Regeln eingeschränkt. So wird beispielsweise jede Sperrung oder Entsperrung gemeinschaftlich von einem Thread und vom Hauptspeicher durchgeführt. Jede Ladeaktion durch einen Thread wird auf eindeutige Weise mit einer Leseaktion durch den Hauptspeicher gepaart, so dass die Ladeaktion auf die Leseaktion folgt. Jede Speicheraktion durch einen Thread wird auf eindeutige Weise mit einer Schreibaktion durch den Hauptspeicher gepaart, so dass auf die Schreibaktion die Speicheraktion folgt.
Eine Threading-Implementation verursacht ein gewisses Maß an Overhead. So erzeugt beispielsweise ein Einprozessorsystem Overhead durch Zeitscheibenunterteilung zwischen Threads. Zusätzliches Overhead entsteht beim Zuordnen und Handhaben des Zugriffs auf den Hauptspeicher und den lokalen Thread-Arbeitsspeicher.
Es besteht Bedarf an einer Prozessorarchitektur, die Multiple-Thread-Betrieb unterstützt und Overhead in Verbindung mit Multiple-Thread-Betrieb reduziert.
OFFENBARUNG DER ERFINDUNG
Ein Prozessor hat eine verbesserte Architektur für Multiple-Thread-Betrieb auf der Basis einer hoch parallelen Struktur mit mehreren unabhängigen parallelen Ausführungspfaden für eine parallele Ausführung über Threads und einen Mehrbefehls-Parallelpfad innerhalb eines Threads. Die mehreren unabhängigen parallelen Ausführungspfade beinhalten Funktionseinheiten, die einen Befehlssatz ausführen, der spezielle Datenhandhabungsbefehle beinhaltet, die in einer Multiple-Thread-Umgebung vorteilhaft sind.
Gemäß einer Ausgestaltung der vorliegenden Erfindung beinhaltet ein Universalprozessor zwei unabhängige Prozessorelemente mit einem einzelnen integrierten Schaltungschip. Die beiden unabhängigen Prozessorelemente führen vorteilhafterweise während des Multiple-Thread-Betriebs simultan zwei unabhängige Threads aus. Wenn nur ein einzelner Thread auf einem ersten der beiden Prozessorelemente ausgeführt wird, dann wird das zweite Prozessorelement vorteilhafterweise für Speicherbereinigung, Just-In-Time (JIT) Kompilation und dergleichen verwendet. Die unabhängigen Prozessorelemente sind zur Illustration VLIW-(lange Instruktionswort-) Prozessoren. So beinhaltet beispielsweise ein illustrativer Prozessor zwei unabhängige VLIW-Prozessorelemente, die jeweils eine Befehlsgruppe oder ein Befehlspaket ausführen, das bis zu vier Befehle beinhaltet, die anderweitig Subbefehle genannt werden. Jeder der Befehle in einer Befehlsgruppe läuft auf einer separaten Funktionseinheit.
Die beiden Threads laufen unabhängig auf den jeweiligen VLIW-Prozessorelementen ab, die jeweils eine Mehrzahl von leistungsstarken Funktionseinheiten aufweisen, die parallel laufen.
In der illustrativen Ausgestaltung haben die VLIW-Prozessorelemente vier Funktionseinheiten, d. h. drei Medienfunktionseinheiten und eine allgemeine Funktionseinheit. Alle illustrativen Medienfunktionseinheiten beinhalten einen Befehl; der sowohl eine Multiplikation als auch eine Addition in einem einzelnen Zyklus, entweder mit Gleitkomma oder mit Festkomma, ausführen.
Gemäß einem Aspekt der vorliegenden Erfindung hat ein einzelner unabhängiger paralleler Ausführungspfad Betriebseinheiten mit Befehlszuführungsblöcken und Befehlsvorbereitungsblöcken, Funktionseinheiten und einer Registerdatei, die von den Betriebseinheiten anderer Pfade der mehreren unabhängigen parallelen Ausführungspfade getrennt und unabhängig sind. Die Befehlszuführungsblöcke beinhalten einen separaten Befehls-Cache-Speicher für die einzelnen unabhängigen parallelen Ausführungspfade, aber die mehreren unabhängigen parallelen Ausführungspfade nutzen einen einzelnen Daten-Cache-Speicher gemeinsam, da mehrere Threads Daten zuweilen gemeinsam nutzen. Der Daten-Cache-Speicher ist ein Dualport-Speicher und lässt Datenzugriff in beiden Ausführungspfaden in einem einzigen Zyklus zu.
Zusätzlich zum Befehls-Cache-Speicher beinhalten die Befehlszuführungsblöcke in einem Ausführungspfad einen Befehlsausrichter und einen Befehlspuffer, die die volle Befehlsgruppe in Vorbereitung auf den Zugriff auf die Registerdatei präzise formatieren und ausrichten. Ein einzelner Ausführungspfad hat eine einzelne Registerdatei, die physikalisch in mehrere Registerdateisegmente unterteilt ist, die jeweils mit einer besonderen Funktionseinheit der mehreren Funktionseinheiten assoziiert sind. Zu einem beliebigen Zeitpunkt haben die Registerdateisegmente, die jeder Funktionseinheit zugewiesen sind, denselben Inhalt. Eine Multiport-Registerdatei ist typischerweise proportional zum Quadrat der Anzahl der Ports auf den von der Schaltung eingenommenen Bereich metallisch begrenzt. Man hat entdeckt, dass ein Prozessor mit einer Registerdateistruktur, die in eine Mehrzahl von separaten und unabhängigen Registerdateien unterteilt ist, eine Layout-Struktur mit einer verbesserten Layout-Effizienz bildet. Die Leseports der gesamten Registerdateistruktur sind unter den separaten und individuellen Registerdateien zugeordnet. Jede der separaten und individuellen Registerdateien hat Schreibports, die der Gesamtzahl der Schreibports in der gesamten Registerdateistruktur entsprechen. Schreibvorgänge werden völlig rundgesendet, so dass alle separaten und individuellen Registerdateien kohärent sind.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale der beschriebenen Ausgestaltungen sind speziell in den beiliegenden Ansprüchen dargelegt. Ausgestaltungen der Erfindung in Bezug auf Struktur und Funktionsweise werden jedoch am besten anhand der nachfolgenden Beschreibung der Begleitzeichnungen verständlich.
1 ist ein schematisches Blockdiagramm, das eine einzelne integrierte Schaltungschip- Implementation eines Prozessors gemäß einer Ausgestaltung der vorliegenden Erfindung veranschaulicht.
2 ist ein schematisches Blockdiagramm des Kerns des Prozessors.
3 ist ein schematisches Blockdiagramm, das eine Ausgestaltung der geteilten Registerdatei illustriert, die für den Gebrauch in dem Prozessor geeignet ist.
4 ist ein schematisches Blockdiagramm, das eine Logikansicht der Registerdatei und der Funktionseinheiten im Prozessor zeigt.
5 ist ein bildliches Schema eines Beispiels für eine Befehlsausführung unter einer Mehrzahl von Medienfunktionseinheiten.
6 illustriert ein schematisches Blockdiagramm einer SRAM-Array, die für die geteilte Multiport-Registerdatei verwendet wird.
7A und 7B zeigen jeweils ein schematisches Blockdiagramm und ein grafisches Diagramm zum Illustrieren der Registerdatei und eines Speicherarray-Einsatzes der Registerdatei.
8 ist ein schematisches Blockdiagramm einer Anordnung der Registerdatei zu vier Registerdateisegmenten.
9 ist ein schematisches Timing-Diagramm, das den zeitlichen Ablauf der Prozessor-Pipeline illustriert.
Die Verwendung derselben Bezugsziffern in verschiedenen Zeichnungen bedeutet ähnliche oder identische Komponenten.
ARTEN DER DURCHFÜHRUNG DER ERFINDUNG
1 ist ein schematisches Blockdiagramm, das einen Prozessor 100 mit einer verbesserten Architektur für Multiple-Thread-Betrieb auf der Basis einer hoch parallelen Struktur mit mehreren unabhängigen parallelen Ausführungspfaden illustriert, hierin als zwei Medienverarbeitungseinheiten 110 und 112 dargestellt. Die Ausführungspfade laufen parallel über Threads ab und beinhalten einen parallelen Mehrbefehlspfad innerhalb eines Threads. Die mehreren unabhängigen parallelen Ausführungspfade beinhalten Funktionseinheiten, die einen Befehlssatz mit speziellen Datenhandhabungsanweisungen ausführen, die in einer Multiple-Thread-Umgebung vorteilhaft sind.
Die Multiple-Thread-Architektur des Prozessors 100 ist für den Gebrauch beim Ausführen von Multiple-Thread-Anwendungen mit einer Sprache wie der Java^TM-Sprache vorteilhaft, die unter einem Multiple-Thread-Betriebssystem auf einer Java Virtual MachineTM mit mehreren Threads läuft. Der illustrative Prozessor 100 beinhaltet zwei unabhängige Prozessorelemente, die Medienverarbeitungseinheiten 110 und 112, die zwei unabhängige parallele Ausführungspfade bilden. Eine Sprache, die mehrere Threads unterstützt, wie z.B. die Programmiersprache JavaTM, erzeugt zwei Threads, die jeweils in den beiden parallelen Ausführungspfaden mit sehr wenig Overhead ablaufen. Die speziellen Anweisungen, die vom Multiple-Thread-Prozessor ausgeführt werden, beinhalten Befehle für den Zugriff auf Arrays, sowie Befehle, die Speicherbereinigung unterstützen.
Eine einzelne integrierte Schaltungschip-Implementation eines Prozessors 100 beinhaltet eine Speicherschnittstelle 102, einen Geometrie-Expander 104, die beiden Medienverarbeitungseinheiten 110 und 112, einen gemeinsam genutzten Daten-Cache-Speicher 106 sowie mehrere Schnittstellensteuerungen. Die Schnittstellensteuerungen unterstützen eine interaktive Graphikumgebung mit Echtzeitbeschränkungen durch Integrieren von Grundkomponenten von Speicher-, Graphik- und Ein-/Ausgabebrückenfunktionalität auf einem einzelnen Chip. Die Komponenten sind über latenzarme Kommunikationskanäle hoher Bandbreite untereinander und eng mit dem Prozessorkern verbunden, um mehrere Datenströme mit hoher Bandbreite effizient und mit geringer Ansprechzeit zu verwalten. Die Schnittstellensteuerungen beinhalten einen UltraPort Architecture Interconnect (UPA) Controller 116 sowie einen Peripheral Component Interconnect (PCI) Controller 120. Die illustrative Speicherschnittstelle 102 hat einen Direct Rambus Dynamic RAM (DRDRAM) Controller. Der gemeinsam genutzte Daten-Cache-Speicher 106 ist ein Dualport-Speicher, der von den Medienverarbeitungseinheiten 110 und 112 gemeinsam genutzt wird, wobei jeder Medienverarbeitungseinheit ein Port zugeordnet ist. Der Daten-Cache-Speicher 106 ist Vierwegsatz-assoziativ, folgt einem Write-Back-Protokoll und unterstützt Hits im Füllpuffer (nicht dargestellt). Der Daten-Cache-Speicher 106 ermöglicht eine schnelle gemeinsame Datennutzung und eliminiert die Notwendigkeit für ein komplexes, fehleranfälliges Cache-Kohärenz-Protokoll zwischen den Medienverarbeitungseinheiten 110 und 112.
Der UPA-Controller 116 hat eine kundenspezifische Schnittstelle, die einen geeigneten Ausgleich zwischen Rechen- und Graphiksubsystemen hoher Leistung erzielt. Der UPA-Controller ist eine Cache-kohärente Prozessor-Speicher-Verbindung. Er erzielt mehrere vorteilhafte Eigenschaften, einschließlich skalierbarer Bandbreite durch die Unterstützung mehrerer Busverbindungen für Daten und Adressen, Pakete, die für eine verbesserte Busauslastung geschaltet sind, höhere Bandbreite und präzise Interrupt-Verarbeitung. Der UPA-Controller führt latenzarme Speicherzugriffe mit Hochkapazitätspfaden zum Speicher durch. Der UPA-Controller beinhaltet eine gepufferte Crossbar-Speicherschnittstelle zum Erhöhen der Bandbreite und zum Verbessern der Skalierbarkeit. Der UPA-Controller unterstützt Hochleistungsgraphik mit Zweizyklus-Einzelwort-Schreibvorgängen auf der 64-Bit-UPA-Verbindung. Die UPA-Verbindungsarchitektur nutzt paketgeschaltete Punkt-zu-Punkt-Meldungen von einem zentralisierten Systemcontroller, um die Cache-Speicherkohärenz aufrechtzuerhalten. Paketschaltung verbessert die Bandbreitenauslastung auf dem Bus, indem die Latenzen wegfallen, die gewöhnlich mit transaktionsgestützten Designs assoziiert sind.
Der PCI-Controller 120 wird als primäre System-E/A-Schnittstelle zum Verbinden von standardmäßigen hochvolumigen, kostenarmen Peripheriegeräten eingesetzt, aber es können auch andere Standardschnittstellen verwendet werden. Der PCI-Bus überträgt effektiv Daten zwischen Peripheriegeräten hoher Bandbreite und Peripheriegeräten niedriger Bandbreite, wie z.B. CD-ROM-Spieler, DVD-Spieler und Digitalkameras.
Zwei Medienverarbeitungseinheiten 110 und 112 sind in einem einzigen integrierten Schaltungschip untergebracht, um eine Ausführungsumgebung unter Nutzung von Thread-Level-Parallelismus zu unterstützen, bei dem zwei unabhängige Threads gleichzeitig ablaufen können. Die Threads können von beliebigen Quellen wie z. B. derselben Anwendung, verschiedenen Anwendungen, dem Betriebssystem oder der Laufzeitumgebung kommen. Parallelismus wird auf Thread-Ebene genutzt, da Parallelismus bei mehr als vier, oder sogar zwei, Befehlen pro Zyklus in Universalcode selten ist. So ist beispielsweise der illustrative Prozessor 100 eine Maschine mit einer Breite von acht mit acht Ausführungseinheiten zum Ausführen von Befehlen. Ein typischer "Universal"-Verarbeitungscode hat einen Befehlslevel-Parallelismus von etwa zwei, so dass durchschnittlich die meisten (etwa sechs) der acht Ausführungseinheiten jeweils im Ruhezustand wären. Der illustrative Prozessor 100 arbeitet mit Thread-Level-Parallelismus und wirkt auf zwei unabhängige Threads und erzielt möglicherweise das Zweifache der Leistung eines Prozessors mit denselben Betriebsmitteln und derselben Taktrate, der jedoch mit traditionellem Non-Thread-Parallelismus arbeitet.
Thread-Level-Parallelismus ist besonders für JavaTM Anwendungen nützlich, die immer mehrere Ausführungsthreads haben. Java^TM Methoden mit "suspend", "resume", "sleep" und dergleichen beinhalten effektive Unterstützung für Programmcode mit mehreren Threads. Darüber hinaus sind Bibliotheken der Java^TM Klasse Thread-sicher und fördern so Parallelismus. Ferner unterstützt das Thread-Modell des Prozessors 100 einen dynamischen Compiler, der als separater Thread mittels einer Medienverarbeitungseinheit 110 läuft, während die zweite Medienverarbeitungseinheit 112 von der aktuellen Anwendung verwendet wird. Im illustrativen System wendet der Compiler Optimierungen auf der Basis von Profil-Feedback-Informationen "beim Laufen" an, während der Ausführungscode dynamisch modifiziert wird, um die Ausführung bei jedem aufeinander folgenden Lauf zu verbessern. So könnte beispielsweise auf einer ersten Medienverarbeitungseinheit 110 eine "Speicherbereinigung" durchgeführt werden, bei der Objekte kopiert oder Zeigerinformationen gesammelt werden, während auf der anderen Medienverarbeitungseinheit 112 die Anwendung abläuft.
Der in 1 gezeigte Prozessor 100 beinhaltet zwar zwei Verarbeitungseinheiten auf einem integrierten Schaltungschip, aber die Architektur ist äußerst skalierbar, so dass ein bis mehrere eng gekoppelte Prozessoren in einer nachrichtenbasierten kohärenten Architektur gebildet und auf demselben Chip untergebracht werden können, um mehrere Ausführungsthreads zu verarbeiten. So entsteht im Prozessor 100 eine Begrenzung der Anzahl der auf einem einzelnen Chip gebildeten Prozessoren aufgrund von Kapazitätsbeschränkungen der integrierten Schaltungstechnologie und nicht aufgrund von Architekturbeschränkungen in Bezug auf die Interaktionen und Verbindungen zwischen Prozessoren.
Der Prozessor 100 ist ein Universalprozessor, der die Medienverarbeitungseinheiten 110 und 112, zwei unabhängige Prozessorelemente in einem einzelnen integrierten Schaltungschip beinhaltet. Die beiden unabhängigen Prozessorelemente 110 und 112 führen vorteilhafterweise zwei unabhängige Threads parallel während des Multiple-Thread-Betriebs aus. Wenn nur ein einziger Thread auf dem Prozessor 100 abläuft, dann führt eines der beiden Prozessorelemente den Thread aus, das zweite Prozessorelement wird vorteilhafterweise für Speicherbereinigung, Just-in-Time (JIT) Kompilation und dergleichen verwendet. Im veranschaulichten Prozessor 100 sind die unabhängigen Prozessorelemente 110 und 112 VLIW-(langes Instruktionswort)-Prozessoren. So beinhaltet z.B. ein illustrativer Prozessor 100 zwei unabhängige VLIW-Prozessorelemente, die jeweils eine Befehlsgruppe oder ein Befehlspaket ausführen, das bis zu vier Befehle beinhaltet. Jeder der Befehle in einer Befehlsgruppe läuft auf einer separaten Funktionseinheit.
Der Gebrauch eines VLIW-Prozessors reduziert vorteilhafterweise die Komplexität, da keine verschiedenen Strukturen wie Scheduler oder Umordnung-Puffer verwendet zu werden brauchen, die in superskalaren Maschinen zur Handhabung von Datenabhängigkeiten verwendet werden. Ein VLIW-Prozessor verwendet typischerweise Software-Planung und Software-Prüfung, um Datenkonflikte und -abhängigkeiten zu prüfen, was Hardware-Steuerschaltungen erheblich vereinfacht.
Die beiden Threads laufen unabhängig auf den jeweiligen VLIW-Prozessorelementen 110 und 112, die jeweils eine Mehrzahl von leistungsstarken Funktionseinheiten aufweisen, die parallel ablaufen. In der in 2 gezeigten illustrativen Ausgestaltung haben die VLIW-Prozessorelemente 110 und 112 vier Funktionseinheiten einschließlich drei Medienfunktionseinheiten 220 und einer allgemeinen Funktionseinheit 222. Alle illustrativen Medienfunktionseinheiten 220 beinhalten einen Befehl, der eine Multiplikation und eine Addition in einem einzelnen Zyklus ausführt, entweder als Gleitkomma- oder als Festkommaoperation. Somit kann ein Prozessor mit zwei VLIW-Prozessorelementen zwölf Gleitkommaoperationen in jedem Zyklus ausführen. Mit einer Ausführungsrate von 500 MHz läuft der Prozessor beispielsweise mit einer 6 Gigaflop-Rate, selbst ohne Berücksichtigung eines Betriebs der allgemeinen Funktionseinheit.
2 zeigt ein schematisches Blockdiagramm des Kerns des Prozessors 100. Die Medienverarbeitungseinheiten 110 und 112 beinhalten jeweils einen Befehls-Cache-Speicher 210, einen Befehlsausrichter 212, einen Befehlspuffer 214, eine Pipeline-Steuereinheit 226, eine geteilte Registerdatei 216, eine Mehrzahl von Ausführungseinheiten sowie eine Lade-/Speichereinheit 218. Im illustrativen Prozessor 100 verwenden die Medienverarbeitungseinheiten 110 und 112 eine Mehrzahl von Ausführungseinheiten zum Ausführen von Befehlen. Die Ausführungseinheiten für eine Medienverarbeitungseinheit 110 beinhalten drei Medienfunktionseinheiten (MFU) 220 und eine allgemeine Funktionseinheit (GFU) 222.
Ein individueller unabhängiger paralleler Ausführungspfad 110 oder 112 hat Betriebseinheiten mit Befehlszuführungsblöcken und Befehlsvorbereitungsblöcken, Funktionseinheiten 220 und 222 und eine Registerdatei 216, die von den Betriebseinheiten anderer Pfade der mehreren unabhängigen parallelen Ausführungspfade separat und unabhängig sind. Die Befehlszuführungsblöcke beinhalten einen separaten Befehls-Cache-Speicher 210 für die individuellen unabhängigen parallelen Ausführungspfade, aber die mehreren unabhängigen parallelen Ausführungspfade nutzen einen einzelnen Daten-Cache-Speicher 106 gemeinsam, da mehrere Threads zuweilen Daten gemeinsam nutzen. Der Daten-Cache-Speicher 106 ist ein Dualport-Speicher und erlaubt einen Datenzugriff auf beide Ausführungspfade 110 und 112 in einem einzigen Zyklus. Die gemeinsame Nutzung des Daten-Cache-Speichers 106 von unabhängigen Prozessorelementen 110 und 112 vereinfacht vorteilhafterweise die Datenhandhabung, so dass kein Cache-Koordinationsprotokoll und das beim Steuern des Protokolls auftretende Overhead nötig ist.
Zusätzlich zum Befehls-Cache-Speicher 210 beinhalten die Befehlszuführungsblöcke in einem Ausführungspfad den Befehlsausrichter 212 und den Befehlspuffer 214, die eine volle Befehlsgruppe von vier Befehlen in Vorbereitung auf einen Zugriff auf die Registerdatei 216 präzise formatieren und ausrichten. Ein einzelner Ausführungspfad hat eine einzelne Registerdatei 216, die physikalisch in mehrere Registerdateisegmente unterteilt ist, die jeweils mit einer bestimmten Funktionseinheit der mehreren Funktionseinheiten assoziiert sind. Zu jedem Zeitpunkt haben die den einzelnen Funktionseinheiten zugeordneten Registerdateisegmente denselben Inhalt. Eine Multiport-Registerdatei ist gewöhnlich proportional zum Quadrat der Anzahl der Ports auf den von der Schaltung belegten Bereich metallisch begrenzt. Der Prozessor 100 hat eine Registerdateistruktur, die in eine Mehrzahl von separaten und unabhängigen Registerdateien unterteilt ist, um eine Layout-Struktur mit verbesserter Layout-Effizienz zu bilden. Die Leseports der gesamten Registerdateistruktur 216 sind unter den separaten und einzelnen Registerdateien zugeordnet. Jede der separaten und einzelnen Registerdateien hat Schreibports, die der Gesamtzahl der Schreibports in der gesamten Registerdateistruktur entsprechen. Schreibvorgänge werden völlig rundgesendet, so dass alle separaten und einzelnen Registerdateien kohärent sind.
Die Medienfunktionseinheiten 220 sind mehrere Einzelbefehls-Mehrdatenpfad- (MSIMD) Medienfunktionseinheiten. Jede der Medienfunktionseinheiten 220 kann parallele 16-Bit-Komponenten verarbeiten. Verschiedene parallele 16-Bit-Operationen liefern die Einzelbefehls-Mehrdatenpfad-Fähigkeit für den Prozessor 100, einschließlich Addieren, Mehrfachaddieren, Verschieben, Vergleichen und dergleichen. Die Medienfunktionseinheiten 220 arbeiten in Kombination als eng gekoppelte digitale Signalprozessoren (DSPs). Jede Medienfunktionseinheit 220 hat einen separaten und individuellen Subbefehlsstrom, aber alle drei Medienfunktionseinheiten 220 laufen synchron, so dass die Subbefehle Pipeline-Stufen im Gleichschritt durchlaufen.
Die allgemeine Funktionseinheit 222 ist ein RISC-Prozessor, der arithmetische Logikeinheit-(ALU) Operationen, Lade- und Speichervorgänge, Verzweigungen und verschiedene spezialisierte und esotere Funktionen wie z.B. parallele Leistungsoperationen, reziproke Quadratwwzelvorgänge und viele. andere ausführen kann. Die allgemeine Funktionseinheit 222, unterstützt weniger gemeinsame parallele Vorgänge als der parallele reziproke Quadratwwzelbefehl.
Der illustrative Befehls-Cache-Speicher 210 ist Zweiwegsatz-assoziativ, hat eine Kapazität von 16 KB und beinhaltet Hardware-Unterstützung zur Aufrechterhaltung von Kohärenz, um dynamische Optimierungen durch selbstmodifizierenden Code zuzulassen. Mit Hilfe von Software wird angezeigt, dass der Befehlsspeicher modifiziert wird, wenn Modifikationen auftreten. Die 16-KB-Kapazität ist für die Durchführung von Graphikschleifen, anderen Multimedia-Tasks oder – Prozessen sowie Java^TM Universalcode geeignet. Kohärenz wird mit Hardware aufrechterhalten, die nichtzuordnenden Write-through-Cache-Speicherbetrieb unterstützt. Selbstmodifizierender Code wird durch die explizite Verwendung des "auf Befehlsraum speichern" Befehls store2i unterstützt. Software benutzt den Befehl store2i zur Aufrechterhaltung von Kohärenz mit dem Befehls-Cache-Speicher 210, so dass die Befehls-Cache-Speicher 210 nicht bei jeder von der Medienverarbeitungseinheit 110 ausgegebenen Einspeicher-Operation gesnoopt zu werden brauchen.
Die Pipeline-Steuereinheit 226 ist zwischen dem Befehlspuffer 214 und den Funktionseinheiten geschaltet und plant die Übertragung von Befehlen zu den Funktionseinheiten. Die Pipeline-Steuereinheit 226 empfängt auch Statussignale von den Funktionseinheiten und der Lade-/Speichereinheit 218 und benutzt die Statussignale zum Durchführen mehrerer Steuerfunktionen. Die Pipeline-Steuereinheit 226 verwaltet ein Scoreboard und erzeugt Verzögerungen und Bypass-Steuerungen. Die Pipeline-Steuereinheit 226 erzeugt auch Traps und verwaltet Spezialregister.
Jede Medienverarbeitungseinheit 110 und 112 beinhaltet eine geteilte Registerdatei 216, eine einzelne Logikregisterdatei mit 128 32-Bit-Registern. Die geteilte Registerdatei 216 ist in eine Mehrzahl von Registerdateisegmenten 224 unterteilt, um eine Multiport-Struktur zu bilden, die zum Reduzieren der integrierten Schaltungschipfläche und zum Reduzieren des Zugriffszeit repliziert wird. Ein separates Registerdateisegment 224 wird jeder der Medienfunktionseinheiten 220 und der allgemeinen Funktionseinheit 222 zugeordnet. In der illustrativen Ausgestaltung hat jedes Registerdateisegment 224 128 32-Bit-Register. Die ersten 96 Register (0–95) im Registerdateisegment 224 sind globale Register. Alle Funktionseinheiten können auf die 96 globalen Register schreiben. Die globalen Register sind über alle Funktionseinheiten (MFU und GFU) kohärent, so dass ein beliebiger, Schreibvorgang auf ein globales Register durch eine beliebige Funktionseinheit zu allen Registerdateisegmenten 224 rundgesendet wird. Register 96-127 in den Registerdateisegmenten 224 sind lokale Register. Auf einer Funktionseinheit zugewiesene lokale Register können auf andere Funktionseinheiten nicht zugreifen und sie sind für diese nicht "sichtbar".
Die Medienverarbeitungseinheiten 110 und 112 sind hoch strukturierte Rechenblöcke, die softwaremäßig geplante Datenrechenvorgänge mit festen, deterministischen und relativ kurzen Befehlslatenzen ausführen, Betriebseigenschaften, die eine Vereinfachung im Hinblick auf Funktion und Zykluszeit ergeben. Die Betriebseigenschaften unterstützen mehrere Befehle, die über einen pragmatischen VLIW-Ansatzausgegeben werden, der Hardware-Verriegelungen vermeidet, um Software zu berücksichtigen, die Operationen nicht ordnungsgemäß plant. Solche Hardware-Verriegelungen sind typischerweise komplex, fehleranfällig und erzeugen mehrere kritische Pfade. Ein VLIW-Instruktionswort beinhaltet immer einen Befehl, der in der allgemeinen Funktionseinheit (GFU) 222 ausgeführt wird, und null bis drei Befehle, die in den Medienfunktionseinheiten (MFU) 220 ausgeführt werden. Ein MFU-Befehlsfeld im VLIW-Instruktionswort beinhaltet ein Operationscode-(Opcode) Feld, drei Source-Register (oder unmittelbare) Felder und ein Zielregisterfeld.
Befehle werden der Reihe nach im Prozessor 100 ausgeführt, aber Ladevorgänge können in Bezug auf andere Befehle und mit Bezug auf andere Ladevorgänge außer der Reihe erfolgen, so dass Ladevorgänge im Befehlsstrom aufwärts bewegt werden können, so dass die Daten vom Hauptspeicher gestreamt werden können. Das Ausführungsmodell eliminiert den Gebrauch und die Overhead-Ressourcen eines Befehlsfensters, Reservationsstationen, einem Umordnungspuffer oder anderen Blöcken zum Anordnen von Befehlen. Der Wegfall der Befehlsordnungsstrukturen und Overhead-Ressourcen ist äußerst vorteilhaft, da die eliminierten Blöcke gewöhnlich einen großen Teil eines integrierten Schaltungschips einnehmen. So nehmen die eliminierten Blöcke beispielsweise etwa 30% der Chipfläche eines Pentium II Prozessors ein.
Um Software-Planungsfehler zu vermeiden, sind die Medienprozessoreinheiten 110 und 112 Hochleistungseinheiten, die aber in Bezug auf Kompilation und Ausfiührung vereinfacht sind. Die Medienverarbeitungseinheiten 110 und 112 werden allgemein als einfache 2-Skalar-Ausführungsmaschine mit vollen Bypass- und Hardware-Verriegelungen auf Ladevorgängen klassifiziert. Die Befehle beinhalten Ladevorgänge, Speichervorgänge, Arithmetik- und Logik-(ALU)-Befehle sowie Verzweigungsbefehle, so dass eine Planung für den Prozessor 100 im Wesentlichen mit der Planung für eine einfache 2-Skalar-Ausführungsmaschine für jede der beiden Medienverarbeitungseinheiten 110 und 112 äquivalent ist.
Der Prozessor 100 unterstützt volle Bypässe zwischen den ersten beiden Ausführungseinheiten innerhalb der Medienverarbeitungseinheit 110 und 112 und hat ein Scoreboard in der allgemeinen Funktionseinheit 222 für Ladevorgänge, so dass der Compiler keine nichtdeterministischen Latenzen aufgrund von Cache-Fehltreffern zu handhaben braucht. Der Prozessor 100 wertet lange Latenzvorgänge aus, die in der allgemeinen Funktionseinheit 222 ausgeführt werden, z.B. ein reziproker Quadratwurzelvorgang, um die Planung über Ausführungseinheiten zu vereinfachen. Das Scoreboard (nicht dargestellt) funktioniert durch Verfolgen eines Datensatzes eines Befehlspakets oder einer Befehlsgruppe von dem Zeitpunkt, an dem der Befehl in eine Funktionseinheit eintritt, bis zu dem Zeitpunkt, an dem der Befehl fertig ist und das Ergebnis vorliegt. Ein VLIW-Befehlspaket enthält einen GFU-Befehl und null bis drei MFU-Befehle. Die Quell- und Zielregister aller Befehle in einem eingehenden VLIW-Befehlspaket werden anhand des Scoreboards geprüft. Eventuelle echte Abhängigkeiten oder Ausgabeabhängigkeiten halten das ganze Paket an, bis das Ergebnis bereit ist. Die Verwendung eines scoreboarded Ergebnisses als Operand bewirkt eine Befehlsausgabe, um für eine ausreichende Anzahl von Zyklen anzuhalten, bis das Ergebnis zur Verfügung steht. Wenn der Referenzierbefehl, der den Halt hervorruft, auf der allgemeinen Funktionseinheit 222 oder der ersten Medienfunktionseinheit 220 abläuft, dann dauert der Halt nur so lange, bis das Ergebnis für einen Intra-Einheit-Bypass zur Verfügung steht. Für den Fall eines load-Befehls, für den es im Daten-Cache-Speicher 106 einen Hit gibt, dauert der Halt möglicherweise nur einen einzigen Zyklus. Wenn der Referenzierbefehl auf der zweiten oder dritten Medienfunktionseinheit 220 vorliegt, dann dauert der Halt so lange, bis das Ergebnis die Write-back-Stufe in der Pipeline erreicht, wo das Ergebnis bei der Übertragung zur geteilten Registerdatei 216 umgangen wird.
Der Scoreboard verwaltet automatisch Ladeverzögerungen, die während eines Lade-Hits auftreten. In einer illustrativen Ausgestaltung gehen alle Ladevorgänge in den Scoreboard, um die Software-Planung zu vereinfachen und NOPs im Befehlsstrom zu eliminieren.
Das Scoreboard dient zum Verwalten der meisten Verriegelungen zwischen der allgemeinen Funktionseinheit 222 und den Medienfunktionseinheiten 220. Alle Ladevorgänge und Nicht-Pipeline-Vorgänge mit langer Latenz der allgemeinen Funktionseinheit 222 werden scoreboarded. Die Vorgänge mit langer Latenz beinhalten Divisionsbefehle idiv, fdiv, reziproke Quadratwurzelbefehle frecsqrt, precsqrt und Leistungsbefehle ppower. Keines der Ergebnisse der Medienfunktionseinheiten 220 wird scoreboarded. Nicht scoreboarded Ergebnisse stehen für nachfolgende Vorgänge an der Funktionseinheit zur Verfügung, die die Ergebnisse nach der Latenz des Befehls erzeugt.
Der illustrative Prozessor 100 hat eine Render-Rate von mehr als fünfzig Millionen Dreiecken pro Sekunde, ohne Berücksichtigung von Betriebssystem-Overhead. Daher liegen Datenzufuhrspezifikationen des Prozessors 100 weit jenseits der Kapazitäten rentabler Speichersysteme. Ausreichende Datenbandbreite wird durch Rendern von komprimierter Geometrie mit dem Geometrie-Expander 104, einer chipinternen Echtzeit-Geometrie-Expansionsmaschine, erzielt. Datengeometrie wird in einem komprimierten Format im Hauptspeicher gespeichert. Zur Render-Zeit wird die Datengeometrie abgerufen und in Echtzeit auf einer integrierten Schaltung des Prozessors 100 expandiert. Der Geometrie-Expander 104 spart vorteilhafterweise Speicherplatz und Speicherübertragungsbandbreite. Die komprimierte Geometrie arbeitet mit einer optimierten verallgemeinerten Maschenstruktur, die explizit die meisten gemeinsam genutzten Scheitelpunkte zwischen Dreiecken aufruft, so dass der Prozessor 100 die meisten Scheitelpunkte nur einmal zu transformieren und zu beleuchten braucht. In einem typischen komprimierten Maschennetz wird der Dreieckdurchsatz der Transform-and-Light-Stufe um einen Faktor von vier oder mehr gegenüber dem Durchsatz für isolierte Dreiecke erhöht. So werden beispielsweise beim Verarbeiten von Dreiecken mehrere Scheitelpunkte parallel bearbeitet, so dass die Auslastungsrate von Ressourcen hoch ist, wodurch sich ein effektiver räumlicher Software-Pipelinebetrieb ergibt. So werden Vorgänge zeitmäßig überlappt, in denen an mehreren Scheitelpunkten gleichzeitig gearbeitet wird, anstatt mehrere Schleifenwiederholungen zeitlich zu überlappen. Für andere Anwendungstypen mit hohem Befehlslevel-Parallelismus werden Schleifen mit hoher Auslösezahl softwaremäßig in eine Pipeline eingereiht, so dass die meisten Medienfunktionseinheiten 220 völlig ausgelastet werden.
3 zeigt ein schematisches Blockdiagramm, das eine Ausgestaltung der geteilten Registerdatei 216 illustriert, die für den Gebrauch im Prozessor 100 geeignet ist. Die geteilte Registerdatei 216 liefert alle Operanden von Prozessorbefehlen, die in den Medienfunktionseinheiten 220 und den allgemeinen Funktionseinheiten 222 ablaufen, und empfängt die Ergebnisse der Befehlsausführung von den Ausführungseinheiten. Die geteilte Registerdatei 216 fungiert als Schnittstelle mit dem Geometrie-Expander 104. Die geteilte Registerdatei 216 ist jeweils Quelle und Ziel von Speicher- bzw. Ladevorgängen.
In dem illustrativen Prozessor 100 hat die geteilte Registerdatei 216 in jeder der Medienverarbeitungseinheiten 110 und 112 128 Register. Graphikverarbeitung stellt eine große Belastung des Registergebrauchs dar. Daher bietet die geteilte Registerdatei 216 eine große Zahl von Registern, so dass die Leistung nicht durch Lade- und Speichervorgänge oder die Handhabung von Zwischenergebnissen wie Graphik-"Fills" und -"Spills" begrenzt ist. Die illustrative geteilte Registerdatei 216 beinhaltet zwölf Leseports und fünf Schreibports, was totale Datenlese- und – schreibkapazität zwischen den Zentralregistern der geteilten Registerdatei 216 und allen Medienfunktionseinheiten 220 und der allgemeinen Funktionseinheit 222 ergibt. Die fünf Schreibports beinhalten einen 64-Bit-Schreibport, der für Ladevorgänge dediziert ist. Die übrigen vier Schreibports haben eine Breite von 32 Bits und dienen für Schreibvorgänge der allgemeinen Funktionseinheit 222 und der Medienfunktionseinheiten 220.
Eine große gesamte Lese- und Schreibkapazität fördert Flexibilität und dient als Einrichtung zum Programmieren von handcodierten Routinen und Compiler-generiertem Code.
Große Multiport-Registerdateien sind typischerweise metallisch begrenzt, so dass der Registerbereich proportional zum Quadrat der Anzahl der Ports ist. Eine 16-Port-Datei ist im Hinblick auf Größe und Geschwindigkeit grob proportional zu einem Wert von 256. Die illustrative geteilte Registerdatei 216 ist in vier Registerdateisegmente 310, 312, 314 und 316 unterteilt, die jeweils drei Leseports und vier Schreibports haben, so dass jedes Registerdateisegment eine Größe und Geschwindigkeit hat, die proportional zu 49 für eine Gesamtfläche für die vier Segmente ist, d. h. proportional zu 196. Die Gesamtfläche. ist somit potentiell kleiner und schneller als eine einzelne Zentralregisterdatei. Schreibvorgänge werden vollständig so rundgesendet, dass alle Dateien kohärent gehalten werden. Logisch gesehen gibt es keinen Unterschied zwischen der geteilten Registerdatei 216 und einer einzelnen Zentralregisterdatei. Vom Standpunkt der Layout-Effizienz her ist die geteilte Registerdatei 216 jedoch äußerst vorteilhaft, weil die Größe verringert und die Leistung verbessert werden kann.
Die neuen Mediendaten, auf die der Prozessor 100 wirkt, sind typischerweise stark komprimiert. Daten werden in einem komprimierten Format vom Hauptspeicher und Ein-/Ausgabegeräten zu Pins des Prozessors 100 übertragen, werden dann auf der den Prozessor 100 enthaltenden integrierten Schaltung expandiert und zur geteilten Registerdatei 216 weitergeleitet.
Das Teilen der Registerdatei in mehrere Segmente in der geteilten Registerdatei 216 in Verbindung mit dem Charakter von Datenzugriffen, bei denen mehrere Bytes verzahnt auf die Mehrzahl von Ausführungseinheiten übertragen werden, führt zu einer hohen Auslastungsrate der Daten, die zum integrierten Schaltungschip geliefert werden, und führt effektiv zu einer weitaus höheren Datenbandbreite, als sie von Universalprozessoren unterstützt wird. Die höchste Datenbandanforderung liegt daher nicht zwischen den Ein-/Ausgabepins und den Zentraleinheiten, sondern stattdessen zwischen der expandierten Datenquelle und dem Rest des Prozessors. Für Graphikverarbeitungen liegt die höchste Datenbandbreitenanforderung zwischen dem Geometrie-Expander 104 und der geteilten Registerdatei 216. Für Videodatenexpansion liegt die höchste Datenbandbreitenanforderung innerhalb der geteilten Registerdatei 216. Datenübertragungen zwischen dem Geometrie-Expander 104 und der geteilten Registerdatei 216 sowie Datenübertragungen zwischen verschiedenen Registern der geteilten Registerdatei 216 können breit sein und mit Prozessorgeschwindigkeit ablaufen, so dass vorteilhafterweise eine große Bandbreite entsteht.
Die Registerdatei 216 ist ein Schwerpunkt für die Erzielung einer sehr großen Bandbreite des Prozessors 100. Der Prozessor 100 überträgt Daten mit einer Mehrzahl von Datenübertragungstechniken. In einem Beispiel für eine Datenübertragungstechnik werden Cachespeicherfähige Daten durch normale Ladevorgänge mit einer geringen Rate von bis zu acht Byte pro Zyklus in die geteilte Registerdatei 216 geladen. In einem weiteren Beispiel werden Streaming- Daten über Gruppenladevorgänge auf die geteilte Registerdatei 216 übertragen. Diese Gruppenladevorgänge übertragen 32 Bytes vom Speicher direkt in acht aufeinander folgende 32-Bit-Register. Der Prozessor 100 verwendet den Streaming-Datenvorgang zum Empfangen von komprimierten Videodaten zur Expansion.
Komprimierte Graphikdaten werden über eine Direktspeicherzugriffseinheit (DMA) im Geometrie-Expander 104 empfangen. Die komprimierten Graphikdaten werden vom Geometrie-Expander 104 expandiert und mit einer hohen Bandbreitenrate über Gruppenladevorgänge, die auf den Geometrie-Expander 104 abgebildet werden, in die geteilte Registerdatei 216 geladen.
Ladevorgänge sind nichtsperrend und werden scoreboarded, so dass eine für Ladevorgänge natürliche lange Latenz durch frühzeitige Planung verborgen werden kann.
Universalanwendungen können die große Registerdatei 216 häufig nicht nutzen. Eine statistische Analyse zeigt, dass Compiler die große Zahl von Registern in der geteilten Registerdatei 216 nicht effektiv nutzen. Aggressive In-Lining-Techniken, die herkömmlicherweise aufgrund der begrenzten Zahl von Registern in konventionellen Systemen beschränkt waren, können jedoch vorteilhafterweise in dem Prozessor 100 eingesetzt werden, um die große Zahl von Registern in der geteilten Registerdatei 216 zu nutzen. In einem Software-System, das die große Zahl von Register im Prozessor 100 nutzt, wird der komplette Satz von Registern nach dem Event eines Thread-(Kontext) Schalters gespeichert. Wenn nur ein paar Register des gesamten Satzes von Registern benutzt werden, dann ist ein Speichern aller Register im vollen Thread-Schalter verschwenderisch. Verschwendung wird im Prozessor 100 dadurch vermieden, dass eine individuelle Markierung von Registern unterstützt wird. Oktanten der 32 Register können als "dirty" markiert werden, wenn sie benutzt werden, und können demzufolge konditionell gespeichert werden.
In verschiedenen Ausgestaltungen wird die geteilte Registerdatei 216 dadurch unterstützt, dass Felder für Globals, Trap-Register und dergleichen dediziert werden.
4 zeigt ein schematisches Blockdiagramm einer Logikansicht der Registerdatei 216 und der Funktionseinheiten im Prozessor 100. Die physikalische Implementation des Kernprozessors 100 wird durch Replizieren einer einzelnen Funktionseinheit zu den drei Medienfunktionseinheiten 220 vereinfacht. Die Medienfunktionseinheiten 220 beinhalten Schaltungen, die verschiedene Arithmetik- und Logikvorgänge ausführen, einschließlich Universalcode, Graphikcode und Video-Image-Sprach-(VIS) Verarbeitung. VIS-Verarbeitung beinhaltet z.B. Videoverarbeitung, Bildverarbeitung, digitale Signalverarbeitungsschleifen (DSP), Sprachverarbeitung sowie Spracherkennungsalgorithmen.
5 zeigt ein vereinfachtes bildliches Schema eines Beispiels für eine Befehlsausführung unter einer Mehrzahl von Medienfunktionseinheiten 220. Durch verschiedene interne Funktionsblöcke innerhalb einer ersten individuellen Medienfunktionseinheit erzeugte Ergebnisse sind innerhalb der ersten Medienfunktionseinheit 510 unmittelbar zugängig, sind aber global nur für andere Medienfunktionseinheiten 512 und 514 und für die allgemeine Funktionseinheit Zyklen nach Eintritt des Befehls in die erste Medienfunktionseinheit 510 zugängig, unabhängig von der tatsächlichen Latenz des Befehls. So können innerhalb einer Funktionseinheit ablaufende Befehle softwaremäßig so geplant werden, dass sie sofort ausgeführt werden, unter Berücksichtigung der tatsächlichen Latenz des Befehls. Im Gegensatz dazu wird erwartet, dass Software, die die Ausführung von Befehlen in verschiedenen Funktionseinheiten plant, die Latenz von fünf Zyklen berücksichtigt. In dem Diagramm repräsentierten die schraffierten Bereiche die Stufe, in der die Pipeline eine Ausführung eines Befehls vollendet und fünf Ergebniswerte erzeugt. Ein Ergebnis steht in einer Funktionseinheit erst dann zur Verfügung, wenn eine letzte schraffierte Stufe beendet ist. In dem Beispiel haben Medienverarbeitungseinheitsbefehle drei verschiedene Latenzen – vier Zyklen für Befehle wie z.B. fmuladd und fadd, zwei Zyklen für Befehle wie pmuladd und einen Zyklus für Befehle wie padd und xor.
Eine interne Bypass-Logik in einer Medienfunktionseinheit 220 leitet zwar Ergebnisse zu Ausführungseinheiten innerhalb derselben Medienfunktionseinheit 220 weiter, aber die interne Bypass-Logik erfasst keine inkorrekten Versuche, ein Ergebnis zu referenzieren, bevor es zur Verfügung steht.
Software, die Befehle plant, für die eine Abhängigkeit zwischen einer bestimmten Medienfunktionseinheit, z.B. 512, und anderen Medienfunktionseinheiten 510 und 514 oder zwischen der jeweiligen Medienfunktionseinheit 512 und der allgemeinen Funktionseinheit 222 auftritt, soll die Fünf-Zyklus-Latenz zwischen dem Eintritt eines Befehls in die Medienfunktionseinheit 512 und der Pipeline-Dauer von fünf Zyklen berücksichtigen.
6 zeigt ein schematisches Blockdiagramm einer Ausgestaltung der Multiport-Registerdatei 216. Eine Mehrzahl von Leseadressbussen RA1 bis RAN führt Leseadressen, die jeweils an Decoderports 616–1 bis 616–N angelegt werden. Decoder-Schaltungen sind in der Fachwelt gut bekannt, und es können beliebige von mehreren Implementationen als Decoder-Ports 616–1 bis 616–N verwendet werden. Wenn eine Adresse an einen der Decoder-Ports 616-1 bis 616-N angelegt wird, dann wird die Adresse decodiert, und ein Leseadresssignal wird von einem Decoder-Port 616 zu einem Register in einer Speicherzellen-Array 618 übertragen. Daten von der Speicherzellenarray 618 werden mit Ausgangsdatentreibern 622 ausgegeben. Daten werden zu und von der Speicherzellenarray 618 unter der Steuerung von Steuersignalen übertragen, die auf einigen der Leitungen der Busse aus der Mehrzahl von Leseadressbussen RA1 bis RAN geführt werden.
Die 7A und 7B zeigen jeweils ein schematisches Blockdiagramm und ein Grafikdiagramm, die die Registerdatei 216 und einen Speicherarray-Einsatz 710 illustrieren. Die Registerdatei 216 ist mit vier Funktionseinheiten 720, 722, 724 und 726 verbunden, die Informationen zur Durchführung von Vorgängen wie Arithmetik-, Logik-, Grafik-, Datenhandhabungsvorgängen und dergleichen liefern. Die illustrative Registerdatei 216 hat zwölf Leseports 730 und vier Schreibports 732. Die zwölf Leseports 730 werden illustrativ drei Ports zugeordnet, die mit jeder der vier Funktionseinheiten verbunden sind. Die vier Schreibports 732 sind zum Empfangen von Daten von allen vier Funktionseinheiten geschaltet.
Die Registerdatei 216 beinhaltet einen Decoder, in 6 dargestellt, für jeden der sechzehn Lese- und Schreibports. Die Registerdatei 216 beinhaltet eine Speicherarray 740, die teilweise in der in 7B illustrierten Einfügung 710 dargestellt ist, und beinhaltet eine Mehrzahl von Wortleitungen 744 und Bitleitungen 746. Die Wortleitungen 744 und Bitleitungen 746 sind einfach ein Satz von Leitungen, die Transistoren (nicht dargestellt) in der Speicherarray 740 verbinden. Die Wortleitungen 744 wählen Register, so dass eine bestimmte Wortleitung ein Register der Registerdatei 216 selektiert. Die Bitleitungen 746 sind ein zweiter Satz von Leitungen, die die Transistoren in der Speicherarray 740 verbinden. Die Wortleitungen 744 und Bitleitungen 746 sind typischerweise im rechten Winkel zueinander angeordnet. In der illustrativen Ausgestaltung sind die Wortleitungen 744 und die Bitleitungen 746 aus Metall konstruiert, das in verschiedenen Ebenen ausgelegt ist, wie z.B eine Metallschicht 2 für die Wortleitungen 744 und eine Metallschicht 3 für die Bitleitungen 746. In anderen Ausgestaltungen können Bitleitungen und Wortleitungen aus anderen Materialien wie z. B. aus Polysilicium bestehen, oder sie können in anderen Ebenen als denen vorliegen, die in der illustrativen Ausgestaltung beschrieben sind, wie im Bereich Halbleiterherstellung bekannt ist. In dem illustrativen Beispiel werden die Wortleitungen 744 um einen Abstand von etwa 1 um voneinander getrennt, und die Bitleitungen 746 sind um etwa 1 um getrennt. Weitere Schaltungsmaße können für verschiedene Prozesse konstruiert werden. Das illustrative Beispiel zeigt eine Bitleitung pro Port, andere Ausgestaltungen können mehrere Bitleitungen pro Port verwenden.
Wenn eine bestimmte Funktionseinheit ein bestimmtes Register in der Registerdatei 216 liest, dann sendet die Funktionseinheit ein Adresssignal über die Leseports 730, das die entsprechenden Wortleitungen zum Zugreifen auf das Register aktiviert. In einer Registerdatei mit einer konventionellen Struktur und zwölf Leseports wird jede Zelle, die ein einzelnes Informationsbit speichert, mit zwölf Wortleitungen verbunden, um eine Adress- und zwölf Bitleitungen zum Führen von von der Adresse gelesenen Daten zu selektieren.
Die vier Schreibports 732 adressieren Register in der Registerdatei mit vier Wortleitungen 744 und vier Bitleitungen 746, die mit jeder Zelle verbunden sind. Die vier Wortleitungen 744 adressieren eine Zelle, und die vier Bitleitungen 746 führen Daten zu der Zelle.
Wenn also die illustrative Registerdatei 216 auf konventionelle Weise mit zwölf Leseports 730 und vier Schreibports 732 für insgesamt sechzehn Ports ausgelegt wäre und die Ports hätten einen Abstand von 1 um, dann hätte eine Speicherzelle eine integrierte Schaltungsfläche von 256 μm² (16 × 16). Die Fläche ist proportional zum Quadrat der Anzahl der Ports.
Die Registerdatei 216 wird alternativ zur Durchführung von einendigen Lese- und/oder einendigen Schreibvorgängen unter Verwendung einer einzelnen Bitleitung pro Port pro Zelle implementiert, oder sie wird zur Durchführung verschiedener Lese- und/oder verschiedener Schreibvorgänge unter Verwendung von zwei Bitleitungen pro Port pro Zelle implementiert.
In dieser Ausgestaltung ist die Registerdatei 216 jedoch nicht in konventioneller Weise ausgelegt und ist stattdessen in eine Mehrzahl von separaten und individuellen Registerdateisegmenten 224 unterteilt. 8 zeigt in einem schematischen Blockdiagramm eine Anordnung der Registerdatei 216 zu vier Registerdateisegmenten 224. Die Registerdatei 216 bleibt als einzelne logische Registerdatei in dem Sinn funktionell, dass die vier Registerdateisegmente 224 dieselbe Anzahl von Registern und dieselben Registerwerte enthalten wie eine konventionelle Registerdatei mit derselben Kapazität, die nicht geteilt ist. Die separaten Registerdateisegmente 224 unterscheiden sich von einer Registerdatei, die nicht geteilt ist, durch den Wegfall von Leitungen, die ansonsten die Ports mit den Speicherzellen verbinden würden. Demgemäß hat jedes Registerdateisegment 224 Verbindungen nur mit drei der zwölf Leseports 730, ein Registerdateisegment mit den anderen neun Leseports verbindende Leitungen fallen weg. Alle Schreibvorgänge werden rundgesendet, so dass jedes der vier Registerdateisegmente 224 Verbindungen mit allen vier Schreibports 732 hat. Somit hat jedes der vier Registerdateisegmente 224 drei Leseports und vier Schreibports für insgesamt sieben Ports. Die individuellen Zellen sind mit sieben Wortleitungen und sieben Bitleitungen verbunden, so dass eine Speicherarray mit einem Abstand von 1 um zwischen Leitungen eine Fläche von etwa 49 μm² hat. In der illustrativen Ausgestaltung haben die vier Registerdateisegmente 224 eine Fläche proportional zu sieben zum Quadrat. Die Gesamtfläche der vier Registerdateisegmente 224 ist somit proportional zu 49 mal 4, d. h. insgesamt 196.
Die geteilte Registerdatei verringert somit vorteilhafterweise die Fläche der Speicherarray in einem Verhältnis von etwa 256/196 (1,3X oder 30%). Die Flächenreduzierung entspricht ferner vorteilhafterweise einer Verbesserung der Geschwindigkeitsleistung aufgrund einer Verringerung der Länge der Wortleitungen 744 und der Bitleitungen 746, die die Arrayzellen verbinden, was die Zeit reduziert, die ein Signal zum Passieren der Leitungen benötigt. Die Verbesserung der Geschwindigkeitsleistung ist aufgrund der strikten Zeitbegrenzungen sehr vorteilhaft, die durch die Spezifikation von Hochleistungsprozessoren auferlegt werden, und auch um eine Registerdatei hoher Kapazität zu erzielen, die bei hohen Geschwindigkeiten funktioniert. So erfolgt beispielsweise das Lesen der Registerdatei 216 typischerweise in einem einzigen Taktzyklus. Für einen Prozessor, der bei 500 MHz arbeitet, wird eine Zykluszeit von zwei Nanosekunden zum Zugreifen auf die Registerdatei 216 auferlegt. Konventionelle Registerdateien haben typischerweise nur bis zu etwa 32 Register im Vergleich zu den 128 Registern in der illustrativen Registerdatei 216 des Prozessors 100. Eine Registerdatei 216, die wesentlich größer ist als die Registerdatei in konventionellen Prozessoren, ist in Hochleistungsvorgängen wie Video- und Graphikverarbeitung äußerst vorteilhaft. Die geringere Größe der Registerdatei 216 ist zum Erfüllen von Zeitbeschränkungen in einer Registerdatei von größerer Kapazität äußerst nützlich.
In 9 illustriert ein vereinfachtes schematisches Timing-Diagramm den zeitlichen Ablauf der Prozessor-Pipeline 900. Die Pipeline 900 beinhaltet neun Stufen einschließlich drei Einleitungsstufen, einer Mehrzahl von Ausführungsphasen und zwei Terminierungsstufen. Die drei Einleitungsstufen werden so optimiert, dass sie nur diejenigen Vorgänge beinhalten, die zum Decodieren von Anweisungen notwendig sind, so dass Sprung- und Rufanweisungen, die in der JavaTM Sprache allgegenwärtig sind, schnell ausgeführt werden. Eine Optimierung der Einleitungsphasen erleichtert vorteilhafterweise eine Abzweigungsvorhersage, da Abzweigungen, Sprünge und Rufe schnell ausgeführt werden und nicht viele Blasen erzeugen.
Die erste der Einleitungsstufen ist eine Abruf-Stufe 910, während der der Prozessor 100 Befehle vom 16 KB Zweiwegsatz-assoziativen Anweisungs-Cache-Speicher 210 abruft. Die abgerufenen Befehle werden im Befehlsausrichter 212 ausgerichtet und in einer Befehlsstufe 912, einer zweiten Stufe der Einleitungsstufen, zum Befehlspuffer 214 weitergeleitet. Der Ausrichtungsvorgang positioniert die Befehle ordnungsgemäß zum Speichern in einem bestimmten Segment der vier Registerdateisegmente 310, 312, 314 und 316 und für die Ausführung in einer assoziierten Funktionseinheit der drei Medienfunktionseinheiten 220 und einer allgemeinen Funktionseinheit 222. In einer dritten Stufe, einer Decodierstufe 914 der Einleitungsstufen, wird das abgerufene und ausgerichtete VLIW-Befehlspaket decodiert, und das Scoreboard (nicht dargestellt) wird gelesen und parallel aktualisiert. Die vier Registerdateisegmente 310, 312, 314 und 316 enthalten jeweils entweder Gleitkommadaten oder ganzzahlige Daten. Die Registerdateien werden in der Decodier-(D)-Stufe gelesen.
Nach der Decodierstufe 914 werden die Ausführungsstufen durchgeführt. Die beiden Endstufen beinhaltet eine Trap-Handling-Stufe 960 und eine Write-back-Stufe 962, während der Ergebnisdaten in die geteilte Registerdatei 216 zurückgeschrieben werden.
Die illustrative Ausgestaltung erörtert zwar speziell Vorteile, die bei der Verwendung der Programmiersprache Java^TM mit dem beschriebenen System erzielt werden, aber es wird auch jede beliebige geeignete Programmiersprache unterstützt. Andere Programmiersprachen, die Multiple-Threading unterstützen, werden im Allgemeinen vorteilhafterweise in dem beschriebenen System verwendet. Die illustrative Ausgestaltung erörtert zwar auch speziell Vorteile, die mit der Verwendung von Java Virtual Machines^TM mit dem beschriebenen System erzielt werden, aber es kann auch jede beliebige geeignete Verarbeitungsmaschine unterstützt werden. Weitere Verarbeitungsmaschinen, die Multiple-Threading unterstützen, werden im Allgemeinen vorteilhafterweise in dem beschriebenen System verwendet.
Ferner hat die illustrative Registerdatei zwar eine Bitleitung pro Port, aber in anderen Ausgestaltungen können mehr Bitleitungen für einen Port zugewiesen werden. Die beschriebenen Wortleitungen und Bitleitungen sind aus einem Metall gebildet. In anderen Beispielen können andere leitende Materialien wie z. B. dotiertes Polysilicium für Verbindungen verwendet werden. Die beschriebene Registerdatei verwendet einendige Lese- und Schreibvorgänge, so dass eine einzelne Bitleitung pro Bit und pro Port verwendet werden kann. In anderen Prozessoren können andere Lese- und Schreibvorgänge mit zweiendigen Leseverstärkern verwendet werden, so dass zwei Bitleitungen pro Bit und pro Port zugewiesen werden, was zu einer größeren Teilung führt. Zweiendige Leseverstärker verbessern die Speichertreue, erhöhen aber die Größe einer Speicherarray erheblich, was die Geschwindigkeitsleistung erheblich belastet. Somit werden die mit der beschriebenen Registerdateistruktur erzielten Vorteile für einen Speicher mit differentialen Lese- und Schreibvorgängen verstärkt. Der Abstand zwischen Bitleitungen und Wortleitungen wurde mit etwa 1 um beschrieben. In einigen Prozessoren kann der Abstand größer als 1 μm sein. In anderen Prozessoren liegt der Abstand zwischen Leitungen bei weniger als 1 μm.

Claims

Prozessor (100), der Folgendes umfasst: eine Mehrzahl von unabhängigen Prozessorelementen (110, 112) in einem einzelnen , integrierten Schaltungschip, der eine jeweilige Mehrzahl von Threads verzahnt während einer mehrere Threads umfassenden Operation ausführen kann, wobei: die Prozessorelemente Funktionseinheiten (220, 222) aufweisen, die fest einigen der Prozessorelementen zugeordnet sind, so dass die Mehrzahl von Threads in den Funktionseinheiten parallel und gleichzeitig ausgeführt werden kann.
Prozessor nach Anspruch 1, bei dem: die Mehrzahl von unabhängigen Prozessorelementen (110, 112) einer jeweiligen Mehrzahl von unabhängigen parallelen Ausführungspfaden entspricht, die parallel über eine Mehrzahl von Threads ablaufen, wobei die Ausführungspfade einen parallelen Multibefehlspfad in einem Thread beinhalten; und die unabhängigen parallelen Ausführungspfade Funktionseinheiten (220, 222) beinhalten, die einen Befehlssatz ausführen, der spezielle Datenverarbeitungsbefehle beinhaltet, die eine Multiple-Thread-Ausführungsumgebung unterstützen, wobei: die Funktionseinheiten fest zwischen den unabhängigen parallelen Ausführungspfaden zugeordnet sind, so dass eine Mehrzahl von Threads in den Funktionseinheiten gleichzeitig ausgeführt werden kann.
Prozessor nach Anspruch 2, bei dem: die Mehrzahl von unabhängigen parallelen Befehlspfaden als eine Mehrzahl von Prozessoren (110, 112) in mehrere Threads umfassenden Applikationen unter Verwendung einer JAVA^TM-Programmiersprache abläuft, die unter einem mehrere Threads umfassenden Betriebssystem auf einer mehrere Threads umfassenden Java Virtual Machine^TM laufen.
Prozessor nach Anspruch 2, bei dem: die Mehrzahl von unabhängigen parallelen Befehlspfaden (110, 112) als eine Mehrzahl von Prozessoren (110, 112) in mehrere Threads umfassenden Applikationen unter Verwendung einer JAVA-Programmiersprache abläuft, die eine Mehrzahl von Threads erzeugt, die jeweils in der Mehrzahl von unabhängigen parallelen Befehlspfaden mit einem Minimum an Threading-Overhead ablaufen.
Prozessor nach Anspruch 2, bei dem: die Mehrzahl von unabhängigen parallelen Befehlspfaden als eine Mehrzahl von Prozessoren (110, 112) in mehrere Threads umfassenden Applikationen unter Verwendung einer JAVA^TM-Programmiersprache abläuft, die spezielle Befehle zum Zugreifen auf Arrays und Befehle unterstützen, die Speicherbereinigung unterstützen.
Prozessor nach Anspruch 1, bei dem: die Mehrzahl unabhängiger Prozessorelemente (110, 112) VLIW-(langes Instruktionswort) Prozessorelemente sind, die eine Mehrzahl von parallel verzahnt arbeitenden Funktionseinheiten (220, 222) beinhalten, wobei die Funktionseinheiten Medienfunktionseinheiten aufweisen, die als digitale Signalprozessoren arbeiten, und eine allgemeine Funktionseinheit, und die Medienfunktionseinheiten einen Befehl zum Ausführen einer Multiplizieroperation und einer Additionsoperation in einem einzigen Zyklus ausführen können, wobei die Muliplizieroperation und die Additionsoperationen Gleitkomma- oder Festkommaoperationen sind.
Prozessor nach Anspruch 1, bei dem: die Mehrzahl von unabhängigen Prozessorelementen (110, 112) in einem einzigen verzahnt ablaufenden Parallelprozessor (100) Folgendes aufweist: eine Befehlszuführungslogik (210); eine Befehlsvorbereitungslogik (212), die mit der Befehlszuführungslogik gekoppelt ist; wobei die Mehrzahl der Funktionseinheiten (220, 222) mit der Befehlszuführungslogik gekoppelt ist und mit der Befehlsvorbereitungslogik gekoppelt ist; eine Registerdatei (216), die mit der Mehrzahl von Funktionseinheiten gekoppelt ist, mit der Befehlszuführungslogik gekoppelt ist und mit der Befehlsvorbereitungslogik gekoppelt ist; wobei die Befehlszuführungslogik, die Befehlsvorbereitungslogik, die Mehrzahl von Funktionseinheiten und die Registerdatei für ein erstes unabhängiges Prozessorelement von der Befehlszuführungslogik, der Befehlsvorbereitungslogik, der Mehrzahl von Funktionseinheiten und der Registerdatei eines zweiten unabhängigen Prozessorelementes unabhängig und separat sind; und einen Daten-Cache-Speicher (106), der mit der Mehrzahl unabhängiger Prozessorelemente gekoppelt ist und von diesen gemeinsam genutzt wird.
Prozessor nach Anspruch 7, bei dem: eine Befehlszuführungslogik einen Befehls-Cache-Speicher (210) für ein erstes unabhängiges Prozessorelement beinhaltet, das von einem Befehls-Cache-Speicher (210) der Befehlszuführungslogik eines zweiten unabhängigen Prozessorelementes unabhängig und separat ist.
Prozessor nach Anspruch 7, bei dem: der Daten-Cache-Speicher (106) mehrtorig ist und Datenzugriffe in Ausführungspfaden der Mehrzahl von unabhängigen Prozessorelementen in einem einzigen Zyklus gewährt.
Prozessor nach Anspruch 7, bei dem: der Daten-Cache-Speicher (106) eine reduzierte Datenverarbeitungslogik hat, die von der gemeinsamen Nutzung des Daten-Cache-Speichers unter der Mehrzahl von unabhängigen Prozessorelementen resultiert, was die Notwendigkeit für ein Cache-Koordinationsprotokoll und Overhead-Logik vermeidet, die sonst beim Steuern des Koordinationsprotokolls gegeben wäre.
Prozessor nach Anspruch 7, bei dem: eine Befehlsvorbereitungslogik einen Ausrichter (212) und einen Befehlspuffer (214) für ein erstes unabhängiges Prozessorelement beinhaltet, das von einem Ausrichter (212) und Befehlspuffer (214) der Befehlszuführungslogik eines zweiten unabhängigen Prozessorelementes unabhängig und separat ist, wobei der Ausrichter eine volle Befehlsgruppe in Vorbereitung auf einen Zugriff auf die Registerdatei aurichtet.
Verfahren zum Betreiben eines Prozessors (100), umfassend die folgenden Schritte: paralleles Ausführen einer Mehrzahl von Ausführungsthreads in einer Mehrzahl von unabhängigen parallelen Ausführungspfaden (110, 112) über eine Mehrzahl von Threads; innerhalb eines Threads Ausführen einer Mehrzahl von Befehlen in einem parallelen Multibefehlspfad in einem aus der Mehrzahl von unabhängigen parallelen Ausführungspfaden; und Ausführen eines Befehlssatzes in einer Mehrzahl von Funktionseinheiten (220, 222), wobei die Funktionseinheiten fest zwischen den unabhängigen parallelen Ausführungspfaden zugeordnet sind, so dass die Mehrzahl von Threads gleichzeitig und parallel ausgeführt werden kann, wobei der Befehlssatz spezielle Datenverarbeitungsbefehle beinhaltet, die eine Multiple-Thread-Umgebung unterstützen.
Verfahren nach Anspruch 12, ferner umfassend das Ausführen der Befehlsthreads in der Mehrzahl von unabhängigen parallelen Befehlspfaden (110, 112) als eine Mehrzahl von Prozessoren in mehrere Threads umfassenden Applikationen unter Verwendung einer Java^TM-Programmiersprache, die unter einem mehrere Threads umfassenden Betriebssystem auf einer mehrere Threads umfassenden Java Virtual Machine^TM läuft.
Verfahren nach Anspruch 12, ferner umfassend das Ausführen der Befehlsthreads in der Mehrzahl von unabhängigen parallelen Befehlspfaden (110, 112) als eine Mehrzahl von Prozessoren in mehrere Threads umfassenden Applikationen unter Verwendung einer Java^TM-Programmiersprache; und Erzeugen einer Mehrzahl von Threads, die jeweils in der Mehrzahl von unabhängigen parallelen Befehlspfaden mit einem Minimum an Threading-Overhead ablaufen.
Verfahren nach Anspruch 12, ferner umfassend den Schritt des Ausführens der Befehlsthreads in der Mehrzahl von unabhängigen parallelen Befehlspfaden (110, 112) als eine Mehrzahl von Prozessoren in mehrere Threads umfassenden Applikationen unter Verwendung einer Java-Programmiersprache; und Zugreifen auf Arrays und Befehle mittels spezieller Befehle, die Speicherbereinigung unterstützen.