DE112004002505T5

DE112004002505T5 - Entkoppeln der Anzahl der logischen Threads von der Anzahl der gleichzeitigen physischen Threads in einem Prozessor

Info

Publication number: DE112004002505T5
Application number: DE112004002505T
Authority: DE
Inventors: Per Hillsboro Hammarlund; Stephan Portland Jourdan; Pierre Michaud; Alexandre Hillsbor Farcy; Morris Hillsboro Marden; Robert Hillsboro Hinton; Douglas Beaverton Carmean
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2003-12-29
Filing date: 2004-12-20
Publication date: 2006-11-23
Also published as: US7797683B2; US20050193278A1; WO2006057647A3; JP2007517322A; WO2006057647A2; CN102193828A; CN1926514A; KR20060111626A; DE112004003142A5; CN102193828B; KR100856144B1; JP4599365B2; CN1926514B

Abstract

Verfahren zum Managen von Threads, umfassend:
Unterstützen einer Mehrzahl von logischen Threads mit einer Mehrzahl von gleichzeitigen physischen Threads.

Description

Erfindungsgebiet
Die Ausführungsformen der vorliegenden Erfindung beziehen sich allgemein auf Computer. Insbesondere beziehen sich die Ausführungsformen auf die Verbesserung von Computerarchitekturen mit gleichzeitigen Ausführungs-Threads.
Diskussion
Mit der zunehmenden Nachfrage nach einer verbesserten Funktionalität in modernen Computern sehen sich Konstrukteure und Hersteller von Prozessoren vor eine Vielzahl von Problemen gestellt. Zum Beispiel hat der ständige Anstieg im Einsatz des Internets und von Multimedienanwendungen dazu geführt, dass mehrere Prozesse oder Ausführungs-Threads gleichzeitig Zugriff auf die Prozessor- und Speicherressourcen verlangen. Obwohl Fortschritte wie Hyper-Threading, wobei einem einzelnen Prozessor ermöglicht wird, gleichzeitig viele Threads zu benutzen, den Prozessordurchsatz erhöht haben, gibt es weiterhin reichlich Verbesserungsmöglichkeiten. Insbesondere besteht der konventionelle Ansatz darin, die logische Komponente des Threads an die physische Komponente des Threads zu koppeln. Leider kann das Koppeln der logischen Komponente des Threads an die physische Komponente des Threads zu Problemen führen, sowohl was den Durchsatz als auch die Spekulation betrifft. Zum Beispiel bestünde ein Ansatz zur Erhöhung des Durchsatzes darin, die Anzahl der gleichzeitigen Threads zu erhöhen. Physische Ressourcen in einem Prozessor sind jedoch durch eine Reihe von Kostenfaktoren begrenzt, die sich sowohl auf die Konstruktion als auch die Herstellung beziehen. Daraus ergibt sich, daß das Ausmaß, in dem der Prozessordurchsatz durch Erhöhung der Anzahl von Threads erhöht werden kann, durch praktische Schwierigkeiten begrenzt ist. Es ist daher ein Multi-Threading-Ansatz erforderlich, mit dem die effektive Anzahl gleichzeitiger Threads erhöht werden kann, ohne die tatsächliche Anzahl von Threads erhöhen zu müssen.
Des weiteren kann Spekulation, die es der logischen Komponente ermöglichen würde, auf mehr als einer der physischen Thread-Komponenten auszuführen, nicht mit der konventionellen Technik des Koppelns der logischen Komponente jedes Threads an die physische Komponente des Threads erzielt werden. Daraus ergibt sich, daß das Ausmaß, bis zu dem die Prozessorleistung verbessert werden kann, ebenfalls begrenzt ist. Ein Multi-Threading-Ansatz ist daher notwendig, der spekulative Ausführung ermöglicht.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die verschiedenen Vorteile der erfindungsgemäßen Ausführungsformen wird ein Fachmann beim Lesen der folgenden Spezifikation und der beigefügten Ansprüche unter Bezugnahme auf die folgenden Zeichnungen erkennen, in denen:
1 ein Diagramm einer beispielhaften Zustandsmaschine gemäß einer erfindungsgemäßen Ausführungsform ist;
2 ein Ablaufdiagramm eines beispielhaften Prozesses ist, mit dem ein logischer Thread gemäß einer erfindungsgemäßen Ausführungsform im aktiven Zustand gehalten werden kann;
3 ein Ablaufdiagramm eines beispielhaften Prozesses ist, mit dem ein logischer Thread gemäß einer erfindungsgemäßen Ausführungsform im Drain-Zustand gehalten werden kann;
4 ein Ablaufdiagramm eines beispielhaften Prozesses ist, mit dem ein logischer Thread gemäß einer erfindungsgemäßen Ausführungsform im Stillstandszustand gehalten werden kann;
5 ein Ablaufdiagramm eines beispielhaften Prozesses ist, mit dem ein logischer Thread gemäß einer erfindungsgemäßen Ausführungsform im Wartezustand gehalten werden kann;
6 ein Diagramm einer Thread-Management-Tabelle gemäß einer erfindungsgemäßen Ausführungsform ist;
7 ein Diagramm einer beispielhaften Durchsatz-Betriebsweise gemäß einer erfindungsgemäßen Ausführungsform ist;
8 ein Diagramm einer beispielhaften spekulativen Betriebsweise gemäß einer erfindungsgemäßen Ausführungsform ist; und
9 ein Diagramm einer beispielhaften Computersystems gemäß einer erfindungsgemäßen Ausführungsform ist.
AUSFÜHRLICHE BESCHREIBUNG
Systeme und Verfahren zum Managen von Threads eignen sich zur Unterstützung einer Mehrzahl logischer Threads mit einer Mehrzahl gleicherzeitiger physischer Threads, um eine größere Effizienz zu erzielen, ohne die mit herkömmlichen Ansätzen verbundenen Herstellungs- und Design-Nachteile in Kauf nehmen zu müssen. In 1 ist ein Diagramm 10 veranschaulicht, welches eine Technik darstellt, wie jeder von mehreren logischen Threads in einem Wartezustand 12, einem aktiven Zustand 14, einem Drain-Zustand 16 und einem Stillstandszustand 18 gehalten werden kann. Jeder logische Thread bleibt so lange in einem aktiven Zustand 14, bis ein oder mehrere Triggerereignisse vorliegen, die sich auf mehrere Probleme, wie Latenz, Fairness, Priorität usw. beziehen können. Wenn ein Triggerereignis vorliegt, tritt der logische Thread in den Drain-Zustand 16 ein, in dem der Prozessor nach einem unterbrechbaren Punkt im logischen Thread sucht. Ein unterbrechbarer Punkt wird als Punkt definiert, für den der Zustand des logischen Threads gesichert werden kann. Der unterbrechbare Punkt richtet sich auch nach dem Typ des angetroffenen Triggerereignisses. Nachdem ein unterbrechbarer Punkt angetroffen wurde, wird der logische Thread so lange in einen Stillstandszustand 18 versetzt, bis entweder keins der Triggerereignisse vorliegt oder ein anderes Ereignis mit höherer Priorität als das ursprüngliche Triggerereignis gemeldet wird. Wenn einer dieser Fälle vorkommt, wird der logische Thread in den Wartezustand 12 umgeschaltet. Wenn zum Beispiel das Triggerereignis ein „Cache Miss" ist, bleibt der logische Thread so lange im Stillstandszustand 18, bis der Speicher das „Cache Miss" bearbeitet hat. Der logische Thread verbleibt so lange im Wartezustand, bis ein verfügbarer physischer Thread angetroffen wird und der logische Thread in den aktiven Zustand 14 umgeschaltet werden kann. Während folglich logische Threads aus dem aktiven Zustand 14 entfernt werden, können andere logische Threads nahtlos in den aktiven Zustand 14 umgeschaltet werden. Dies führt zu einem einzigartigen Entkopplungseffekt zwischen den logischen Threads und den gleichzeitigen physischen Threads.
Mit Bezug auf 2 ist ein Ansatz zum Halten eines logischen Threads im aktiven Zustand in größerem Detail dargestellt. Beginnend mit Verarbeitungsblock 20 werden die mit einem logischen Thread verbundenen Makroanweisungen auf einem NIP (Hext Instruction Pointer) eines physischen Threads abgebildet. Ein logischer Thread kann als Folge von Makroanweisungen, die zu Mikro-Operationen (oder uops) dekodiert werden, betrachtet werden. Zum Beispiel kann eine „Call" Makroanweisung zu „Store", „Test" und „Jump" uops dekodiert werden. Jeder gleichzeitige physische Thread weist einen entsprechenden NIP auf, der effektiv die Adresse der zu verarbeitenden Makroanweisung darstellt. Während demzufolge Makroanweisungen eines gegebenen logischen Threads auf dem NIP abgebildet werden, können sie geholt, zu uops dekodiert und in den Rest der Prozessor-Pipeline eingespeist werden.
Diese Techniken gelten sowohl für RISC-Architekturen (RISC = Reduced Instruction Set Computer) als auch für CISC-Architekturen (CISC = Complex Instruction Set Computer). Die Umwandlung von Makroanweisungen in Mikrooperationsfolgen ist nicht unbedingt erforderlich.
In Block 22 wird der Prozessor auf eine oder mehrere Triggerereignisse überwacht. Triggerereignisse sind zum Beispiel Speicherlatenz-Ereignisse, „Schlaf-Anforderungen" und Thread-Prioritätsereignisse, sie sind aber nicht auf diese Ereignisse beschränkt. Zum Beispiel kann ein Speicherlatenz-Ereignis ein Cache Miss sein, bei dem Daten mit einer relativ langen Latenz aus dem Speicher zu lesen sind. In diesem Fall wird das Triggerereignis von der Ausführungs-Pipeline an die Thread-Management-Logik gesendet. Ein weiteres Beispiel für ein Speicherlatenz-Ereignis ist ein Cache Miss, bei dem Daten oder Anweisungen aus Speichern geholt werden müssen, die weiter unten in der Speicherhierarchie liegen (eine längere Latenz haben). Die Vorhersage von Cache Misses kann mit jeder verfügbaren Technik erfolgen. Zum Beispiel könnte ein Algorithmus den im Cache fehlenden Lade-Mikooperationen eine höhere Wahrscheinlichkeit zuweisen, wenn zur Dekodierungszeit die Lade-Mikrooperation jünger als eine nicht aufgelöste Abzweigung ist. Die jeweilige Vorhersagetechnik steht nicht im Mittelpunkt der vorliegenden Diskussion, und das obige Beispiel ist nur eine Möglichkeit, ein Triggerereignis zu erzeugen. Ein Triggerereignis kann auch die Tatsache sein, daß das Vertrauen in die Vorhersage einer bedingten Abzweigung schwach ist – in einer Situation, in der verfügbare Threads im Wartezustand sind, bringt es vielleicht mehr, diese logischen Threads auszuführen als den aktuellen logischen Thread im spekulativen Modus auszuführen. Das Vertrauen in die Stärke der Vorhersage kann auch von der Priorität des aktuellen logischen Threads abhängig sein.
Ein weiterer Triggereignistyp ist eine Schlafanforderung, zum Beispiel, wenn eine HALT- oder MONITOR/MWAIT Anweisung ausgeführt wird, die die Thread-Management-Architektur anweisen könnte, die Verarbeitung eines logischen Threads zu unterbrechen, bis eine Speicherung auf eine bestimmte Adresse angetroffen wird, oder bis ein „Wiederbelebungs"-Signal empfangen wird (zum Beispiel ein externes Interrupt). Ein Triggerereignis kann auch ein Interrupt-Befehl von einem anderen logischen Thread sein, der eine höhere Priorität als der aktive logische Thread hat. Ein Beispiel für einen solchen logischen Thread mit hoher Priorität könnte ein Bildschirmaktualisierungs-Thread sein, der ein unerwünschtes „Flickern" des Bildschirms bewirkt, wenn der Zugriff auf einen physischen Thread fehlschlägt. Des weiteren könnte ein Thread-Prioritätsereignis gemäß einer Fairness-Regel eintreten, die den ungewichteten oder gewichteten Zugriff auf gleichzeitige physische Threads durch die logischen Threads gestattet.
Auf jeden Fall, wenn bei Block 24 bestimmt wird, daß ein oder mehrere Triggerereignisse vorliegen, kann das Abbilden bei Block 26 angehalten und der logische Thread bei Block 28 auf den Drain-Zustand umgeschaltet werden. Bei Block 30 wird der logische Thread im aktiven Zustand gehalten, bis ein oder mehrere Triggerereignisse vorliegen.
Mit Bezug auf 3 ist ein Ansatz zum Halten eines logischen Threads im Drain-Zustand in größerem Detail dargestellt. Bei Block 32 wird der logische Thread auf einen unterbrechbaren Punkt überwacht. Wie bereits besprochen, werden während der Verarbeitung eines logischen Threads typisch Makroanweisungen in eine oder mehrere uops dekodiert. Die uops können, wie angemessen, als entweder den Anfang einer Makroanweisung (BOM) oder das Ende einer Makroanweisung (EOM) bezeichnend markiert werden. In diesem Fall könnte der unterbrechbare Punkt mit einer uop zusammenfallen, die mit EOM markiert ist. Ein solcher Ansatz würde bestimmten Schwierigkeiten vorbeugen, die mit gegenseitiger Abhängigkeit verbunden sind, und würde die Effizienz weiter verbessern. Der unterbrechbare Punkt könnte auch lediglich dem Entfernen der letzten uop aus dem betreffenden logischen Thread entsprechen. Wenn bei Block 34 bestimmt wird, dass ein unterbrechbarer Punkt angetroffen wurde, wird bei Block 36 der logische Thread in den Stillstandszustand umgeschaltet. Bei Block 38 wird der logische Thread im Drain-Zustand gehalten, bis ein unterbrechbarer Punkt angetroffen wird.
Mit Bezug auf 4 ist ein Ansatz zum Halten eines logischen Threads im Stillstandszustand in größerem Detail dargestellt. Im Einzelnen wird bei Block 40 der Prozessor auf ein oder mehrere Triggervereignisse überwacht. Wie bereits erklärt, können Triggerereignisse zum Beispiel Speicherlatenz-Ereignisse, „Schlaf-Anforderungen" und Thread-Prioritätsereignisse usw. sein, sie sind aber nicht auf diese Ereignisse beschränkt. Wenn bei Block 42 bestimmt wird, dass keins der Triggerereignisse vorliegt, wird bei Block 44 der logische Thread in den Wartezustand umgeschaltet. Bei Block 46 wird der logische Thread im Stillstandszustand gehalten, bis keins der Triggerereignisse vorliegt. Zum Beispiel wird der logische Thread im Stillstandszustand gehalten, bis ein "Cache Miss" Triggerereignis bearbeitet wurde und die Daten anwesend sind. Es wird darauf hingewiesen, daß das Triggerereignis, welches bewirkt, daß der logische Thread in den Drain-Zustand umgeschaltet wird, das gleiche oder ein anderes Ereignis sein kann als das, mit dem der logische Thread aus dem Stillstandszustand herausversetzt wird.
Es wird darauf hingewiesen, daß das Triggerereignis, welches bewirkt, daß der logische Thread in den Drain-Zustand umgeschaltet wird, das gleiche oder ein anderes Ereignis sein kann als das, mit dem der logische Thread aus dem Stillstandszustand herausversetzt wird. Zum Beispiel kann der logische Thread durch Ausführen einer HALT-Anweisung in den Stillstandszustand versetzt werden und kann so lange im Stillstandszustand verharren, bis ein externes Interrupt empfangen wird. Der logische Thread kann auch durch Ausführen einer Lade-Anweisung, die das Cache verfehlt, in den Stillstandszustand versetzt werden und durch den Empfang eines externen Interrupts aus dem Stillstandszustand herausgezwungen werden, weil das Bearbeiten eines externen Interrupts oft wichtiger ist, als darauf zu warten, bis ein spekulatives Cache Miss abgewickelt ist.
Mit Bezug auf 5 ist ein Ansatz zum Halten eines logischen Threads im Wartezustand in größerem Detail dargestellt. Im Einzelnen wird bei Block 48 die Mehrzahl der gleichzeitigen physischen Threads auf einen verfügbaren physischen Thread überwacht. Wenn bei Block 50 bestimmt wird, daß der verfügbare physische Thread angetroffen wurde, wird bei Block 52 der logische Thread in den aktiven Zustand umgeschaltet. Bei Block 54 wird der logische Thread im Wartezustand gehalten, bis der verfügbare physische Thread angetroffen wird. Folglich sind alle logischen Threads, die sich im Wartezustand befinden, bereit, auf einem physischen Thread ausgeführt zu werden. Wenn ein physischer Thread verfügbar wird, wird ein logischer Thread ausgewählt und in den aktiven Zustand versetzt. Ein physischer Thread kann gemäß den oben genannten Beispielen verfügbar werden. Die Auswahl eines logischen Threads kann auf der Priorität zwischen den logischen Threads und/oder auf Fairness-Erfordernissen basieren, ist aber nicht darauf begrenzt.
Mit Bezug auf 6 ist eine Thread-Management-Tabelle 56 dargestellt. Die Thread-Management-Tabelle 56 speichert logische Thread-Informationen, die einen Zustand und ein oder mehrere Triggerereignisse für jeden der Mehrzahl von logischen Threads identifizieren können. Zum Beispiel befindet sich der dargestellte T₀ im aktiven Zustand und kann durch eine spezifische Speicheranforderung oder eine externe Speicherung auf die Überwachungsadresse AF09 getriggert werden. Thread T₁ andererseits befindet sich im Stillstandszustand und wird durch die externe Speicherung auf die Überwachungsadresse AF09 und einen „MWAIT" Befehl getriggert. Weitere Information, wie der bei Aktivierung zu benutzende IP und das zur Unterstützung der logischen Threads benötigte Hardware-Ressourcen-Profil, kann ebenfalls in der Thread-Management-Tabelle 56 gespeichert werden. In diesem Zusammenhang wird darauf hingewiesen, daß die Ressourcen nicht gleichmäßig auf all die logischen Threads verteilt werden müssen. Ressourcen sind unter anderem die temporären Register im Prozessor, die zur Unterstützung schneller spekulativer Ausführung dienen, wobei mehr Ressourcen typische schnellere Ausführung bedeuten. Tatsächlich kann jede Ressource im System in das Hardware-Ressourcen-Profil aufgenommen und in dieser Weise gesteuert werden. Zum Beispiel könnten sehr anspruchsvollen logischen Threads mehr Ressourcen als weniger anspruchsvollen Threads zugewiesen werden. Ressourcenzuweisung kann auch den Einsatz von Priorität, Leistungsrückmeldung oder Fairness-Einsatz beinhalten, ist jedoch nicht darauf begrenzt. Es wird ferner darauf hingewiesen, daß die Komponenten der Thread-Management-Tabelle 56 entsprechend den praktischen Implementierungsbelangen in verschiedenen Teilen des Prozessors verteilt werden können und nicht zentral angeordnet sein müssen.
In 7 ist ein Beispiel dargestellt, in dem die Mehrzahl der logischen Threads 58 größer als die Mehrzahl der gleichzeitigen physischen Threads 60 ist. In einem solchen Fall wird die Thread-Management-Architektur im „Durchsatzmodus" betrieben, weil die gleichzeitigen physischen Threads 60 durch kontinuierliche Aktivierung der verarbeitungsbereiten logischen Threads so beschäftigt wie möglich gehalten werden können. In 8 andererseits ist die Anzahl der logischen Threads 62 kleiner als die Mehrzahl der gleichzeitigen physischen Threads 64, wodurch ein spekulativer Betriebsmodus erzielt wird. Spekulation wird dadurch erzielt, daß zusätzliche gleichzeitige physische Threads dem gleichen logischen Thread zugewiesen werden, wenn Programmaufruf e oder andere indirekte Programmstrukturen angetroffen werden. Im Falle eines Programmaufrufs läßt sich zum Beispiel erkennen, daß ein ordnungsgemäß geschriebenes Programm mit einer " Call"-Anweisung im Endeffekt zum „Call"-Punkt zurückkehrt. Dementsprechend kann es wünschenwert sein, den zusätzlichen gleichzeitigen physischen Thread am erwarteten Rückkehrpunkt zu starten und die spekulative Rückkehr gegenüber der tatsächlichen Rückkehr zu prüfen, wenn die tatsächliche Rückkehr eintritt. Wenn die Prüfung erfolgreich ist, sind die uops, die anhand des zusätzlichen gleichzeitigen physischen Threads verarbeitet wurden, gültig. Es wird außerdem darauf hingewiesen, daß eine Thread-Management-Architektur ohne weiteres für Hybrid-Betrieb konfiguriert werden kann, wobei die oben beschriebenen Durchsatz- und Spekulationsmoden gleichzeitig betrieben werden.
Mit Bezug auf 9 ist ein Computersystem 66 dargestellt. Computersystem 66 weist einen Systemspeicher 68 zum Speichern von Makroanweisungen auf. Der Systemspeicher kann einen Direktzugriffsspeicher (RAM), einen Nurlesespeicher (ROM), einen Flash-Speicher usw. enthalten. Ein Systembus 70 ist an den Systemspeicher und einen Prozessor 72 gekoppelt, um Makroanweisungen abzurufen. Der Prozessor 72 weist eine Thread-Management-Architektur 74 mit einer Zustandsmaschine 76 und einem Hardware-Sequenzer 78 auf. Die Zustandsmaschine 76 kann auf ähnliche Weise wie die im Diagramm 10 (1) dargestellte Zustandsmaschine arbeiten. Die Zustandsmaschine 76 unterstützt eine Mehrzahl von den Makroanweisungen entsprechenden logischen Threads mit einer Mehrzahl gleichzeitiger physischer Threads, indem sie jeden der Mehrzahl von logischen Threads im Wartezustand, im aktiven Zustand, im Drain-Zustand oder im Stillstandszustand hält. Der Hardware-Sequenzer 78 überwacht die Mehrzahl der gleichzeitigen physischen Threads auf einen verfügbaren physischen Thread, der den logischen Threads entspricht. Die Zustandsmaschine 76 hält die logischen Threads im Wartezustand, bis ein verfügbarer physischer Thread angetroffen wird. Es wird darauf hingewiesen, daß, obwohl im dargestellten Beispiel die der Mehrzahl von logischen Threads entsprechenden Makroanweisungen im Systemspeicher gespeichert werden, Anweisungen und ihre entsprechenden uops auch aus einem „Chip"-Speicher wie einem Verfolgungs-Cache, einem Anweisungs-Cache usw. abgerufen werden können.
Es wird ferner darauf hingewiesen, daß die genaue Anzahl von Zuständen, in denen ein logischer Thread existieren kann, je nach Umständen variieren kann. Zum Beispiel kann, um eine tatsächliche Implementierung zu ermöglichen, der Drain-Zustand in viele Zustände aufgeteilt werden, wobei jeder Subzustand ein Teil der Drain-Operation darstellt.
Anhand der obigen Beschreibung wird der Fachmann erkennen, daß die allgemeine Lehre der vorliegenden Erfindung in einer Vielfalt von Formen implementiert werden kann. Folglich sollte, obwohl die Erfindung mit Bezug auf bestimmte Beispiele beschrieben wurde, der Geltungsbereich der Erfindung nicht auf diese beschränkt werden, da dem Fachmann nach Studierung der Zeichnungen, der Spezifikation und der nachfolgenden Ansprüche andere Modifikationen einfallen werden.
ZUSAMMENFASSUNG
Systeme und Verfahren zum Managen von Threads dienen zur Unterstützung einer Mehrzahl von logischen Threads mit einer Mehrzahl von gleichzeitigen physischen Threads, in denen die Anzahl der logischen Threads größer oder kleiner als die Anzahl der physischen Threads sein kann. In einem Ansatz wird jeder der Mehrzahl von logischen Threads in einem Wartezustand, einem aktiven Zustand, einem Drain-Zustand und einem Stillstandszustand gehalten. Eine Zustandsmaschine und ein Hardware-Sequenzer können dazu verwendet werden, den Zustand der logischen Threads auf der Grundlage von Triggerereignissen und abhängig davon umzuschalten, ob in den logischen Threads ein unterbrechbarer Punkt angetroffen wurde. Die logischen Threads laufen auf den physischen Threads, um beispielsweise Prioritäts-, Leistungs- oder Fairnessziele zu erfüllen. Es ist auch möglich, die Ressourcen anzugeben, die für jeden logischen Thread zur Verfügung stehen, um diese und andere Ziele zu erfüllen. In einem Beispiel kann ein einzelner logischer Thread spekulativ mehr als einen physischen Thread benutzen, abhängig von der Auswahl des physischen Threads, der engagiert werden soll.

Claims

Verfahren zum Managen von Threads, umfassend: Unterstützen einer Mehrzahl von logischen Threads mit einer Mehrzahl von gleichzeitigen physischen Threads.
Verfahren nach Anspruch 1, ferner umfassend das Halten jeder der Mehrzahl von logischen Threads in einem Wartezustand, einem aktiven Zustand, einem Drain-Zustand und einem Stillstandszustand.
Verfahren nach Anspruch 2, wobei ein erster logischer Thread im aktiven Zustand gehalten wird, ferner umfassend: Abbilden von mit dem ersten logischen Thread verknüpften Makroanweisungen auf einem NIP (Nächster Anweisungszeiger) eines physischen Threads; und Überwachen eines Prozessors auf ein Triggerereignis; Halten des ersten logischen Threads im aktiven Zustand, bis das Triggerereignis vorliegt.
Verfahren nach Anspruch 3, ferner umfassend: Anhalten des Abbildens, wenn das Triggerereignis vorliegt; und Umschalten des ersten logischen Threads in den Drain-Zustand.
Verfahren nach Anspruch 3, wobei das Triggerereignis mindestens ein Speicherlatenzereignis, eine Schlafanforderung oder ein Thread-Prioritätsereignis umfaßt.
Verfahren nach Anspruch 2, wobei ein erster logischer Thread im Drain-Zustand gehalten wird, ferner umfassend: Überwachen des ersten logischen Threads auf einen unterbrechbaren Punkt; und Halten des ersten logischen Threads im Drain-Zustand, bis der unterbrechbare Punkt angetroffen wird.
Verfahren nach Anspruch 6, ferner umfassend das Umschalten des ersten logischen Threads in den Stillstandszustand, wenn der unterbrechbare Punkt angetroffen wird.
Verfahren nach Anspruch 6, wobei der unterbrechbare Punkt entweder einem Ende einer Makroanweisung im ersten logischen Thread oder einem Zurückziehen einer mit dem ersten logischen Thread verknüpften letzten Mikrooperation entspricht.
Verfahren nach Anspruch 2, wobei ein erster logischer Thread im Stillstandszustand gehalten wird, ferner umfassend: Überwachen eines Prozessors auf ein Triggerereignis; und Halten des ersten logischen Threads im Stillstandszustand, bis das Triggerereignis nicht vorliegt.
Verfahren nach Anspruch 9, ferner umfassend Umschalten des ersten logischen Threads in den Wartezustand, wenn das Triggerereignis nicht vorliegt.
Verfahren nach Anspruch 9, ferner Umschalten des ersten logischen Threads in den Wartezustand, wenn ein anderes Ereignis mit höherer Priorität als das Triggerereignis gemeldet wird.
Verfahren nach Anspruch 9, wobei das Triggerereignis mindestens ein Speicherlatenzereignis, eine Schlafanforderung oder ein Thread-Prioritätsereignis enthält.
Verfahren nach Anspruch 2, wobei ein erster logischer Thread im Wartezustand gehalten wird, ferner umfassend: Überwachen der Mehrzahl von gleichzeitigen physischen Threads auf einen verfügbaren physischen Thread; und Halten des ersten logischen Threads im Wartezustand, bis der verfügbare physische Thread angetroffen wird.
Verfahren nach Anspruch 13, ferner umfassend Umschalten des ersten logischen Threads in den aktiven Zustand, wenn der verfügbare physische Thread angetroffen wird.
Verfahren nach Anspruch 1, ferner umfassend Speichern der Thread-Information in einer Thread-Management-Tabelle, wobei die Thread-Information einen Zustand, ein oder mehrere Triggerereignisse und einen linearen Anweisungszeiger für jeden der Mehrzahl von logischen Threads umfaßt.
Verfahren nach Anspruch 15, wobei die Thread-Information ferner ein Ressourcenerfordernisprofil für jeden der Mehrzahl von logischen Threads umfaßt.
Verfahren nach Anspruch 1, wobei eine Mehrzahl von logischen Threads größer als die Mehrzahl der gleichzeitigen physischen Threads ist.
Verfahren nach Anspruch 1, wobei eine Mehrzahl von logischen Threads kleiner als die Mehrzahl der gleichzeitigen physischen Threads ist.
Verfahren zur Unterstützung einer Mehrzahl von logischen Threads mit einer Mehrzahl von gleichzeitigen physischen Threads, umfassend: Abbilden von mit einem ersten logischen Thread verknüpften Makroanweisungen auf einen NIP (nächster Anweisungszeiger) eines gleichzeitigen physischen Threads; Überwachen eines Prozessors auf ein Triggerereignis zu einer ersten Zeit; Halten des ersten logischen Threads in einem aktiven Zustand, bis das Triggerereignis vorliegt; Anhalten des Abbildens und Umschalten des ersten logischen Threads in einen Drain-Zustand, wenn das Triggerereignis vorliegt; Überwachen des ersten logischen Threads auf einen unterbrechbaren Punkt; Halten des ersten logischen Threads im Drain-Zustand, bis der unterbrechbare Punkt angetroffen wird; Schalten des ersten logischen Threads in einen Stillstandszustand, wenn der unterbrechbare Punkt angetroffen wird; Überwachen eines Prozessors auf ein Triggerereignis zu einer zweiten Zeit; Halten des ersten logischen Threads im Stillstandszustand, bis das Triggerereignis nicht vorliegt; Schalten des ersten logischen Threads in einen Wartezustand, wenn das Triggerereignis nicht vorliegt; Überwachen der Mehrzahl von gleichzeitigen physischen Threads auf einen verfügbaren physischen Thread; Halten des ersten logischen Threads im Wartezustand, bis der verfügbare physische Thread angetroffen wird; und Umschalten des ersten logischen Threads in den Wartezustand, wenn der verfügbare physische Thread angetroffen wird.
Verfahren nach Anspruch 19, wobei das Triggerereignis mindestens ein Speicherlatenzereignis, eine Schlafanforderung oder ein Thread-Prioritätsereignis umfaßt.
Verfahren nach Anspruch 19, wobei der unterbrechbare Punkt entweder einem Ende einer Makroanweisung im ersten logischen Thread oder einem Zurückziehen einer mit dem ersten logischen Thread verknüpften letzten Mikrooperation entspricht.
Verfahren nach Anspruch 19, ferner umfassend Speichern der Thread-Information in einer Thread-Management-Tabelle, wobei die Thread-Information einen Zustand, ein oder mehrere Triggerereignisse und einen linearen Anweisungszeiger für jeden der Mehrzahl von logischen Threads identifiziert.
Thread-Management-Architektur, umfassend: eine Zustandsmaschine zur Unterstützung einer Mehrzahl von logischen Threads mit einer Mehrzahl von gleichzeitigen physischen Threads durch Halten jeder der Mehrzahl von logischen Threads in einem Wartezustand, einem aktiven Zustand, einem Drain-Zustand und einem Stillstandszustand.
Thread-Management-Architektur nach Anspruch 23, wobei die Zustandsmaschine zum Abbilden von mit einem ersten logischen Thread verknüpften Makroanweisungen auf einem nächsten Anweisungszeiger des physischen Threads, zur Überwachung eines Prozessors auf ein Triggerereignis und zum Halten des ersten logischen Threads in einem aktiven Zustand dient, bis das Triggerereignis vorliegt.
Thread-Management-Architektur nach Anspruch 23, wobei die Zustandsmaschine zur Üpberwachung eines ersten logischen Threads auf einen unterbrechbaren Punkt und zum Halten des ersten logischen Threads im Drain-Zustand dient, bis der unterbrechbare Punkt angetroffen wird.
Thread-Management-Architektur nach Anspruch 23, wobei die Zustandsmaschine zur Überwachung eines Prozessors auf ein Triggerereignis und zum Halten eines ersten logischen Threads im Stillstandszustand dient, bis das Triggerereignis nicht vorliegt.
Thread-Management-Architektur nach Anspruch 23, ferner umfassend einen Hardware-Sequenzer, der zur Überwachung der Mehrzahl von gleichzeitigen physischen Threads auf einen verfügbaren physischen Thread dient, wobei die Zustandsmaschine zum Halten des ersten logischen Threads im Wartezustand dient, bis der verfügbare physische Thread angetroffen wird.
Computersystem, umfassend: einen Direktzugriffsspeicher zum Speichern von Makroanweisungen; einen Systembus, der an den Speicher gekoppelt ist; und einen Prozessor, der an den Systembus gekoppelt ist, um die Makroanweisungen abzurufen, wobei der Prozessor eine Thread-Management-Architektur mit einer Zustandsmaschine aufweist, die zur Unterstützung einer Mehrzahl der den Makroanweisungen entsprechenden logischen Threads mit einer Mehrzahl von gleichzeitigen physischen Threads dient, indem jeder der Mehrzahl von logischen Threads in einem Wartezustand, einem aktiven Zustand, einem Drain-Zustand und einem Stillstandszustand gehalten wird.
Computersystem nach Anspruch 28, wobei die Zustandsmaschine zum Abbilden von mit einem ersten logischen Thread verknüpften Makroanweisungen auf einem nächsten Anweisungszeiger eines physischen Threads, zum Überwachen des Prozessors auf ein Triggerereignis und zum Halten des ersten logischen Threads im aktiven Zustand dient, bis das Triggerereignis vorliegt.
Computersystem nach Anspruch 28, wobei die Zustandsmaschine zur Überwachung eines ersten logischen Threads auf einen unterbrechbaren Punkt und zum Halten des ersten logischen Threads im Drain-Zustand dient, bis der unterbrechbare Punkt angetroffen wird.
Computersystem nach Anspruch 28, wobei die Zustandsmaschine zur Überwachung des Prozessors auf ein Triggerereignis und zum Halten des ersten logischen Threads im Stillstandszustand dient, bis das Triggerereignis nicht vorliegt.
Computersystem nach Anspruch 28, wobei die Thread-Management-Architektur ferner einen Hardware-Sequenzer enthält, der zur Überwachung der Mehrzahl von gleichzeitigen physischen Threads auf einen verfügbaren physischen Thread dient, der einem ersten logischen Thread entspricht, wobei die Zustandsmaschine zum Halten des ersten logischen Threads im Wartezustand dient, bis der verfügbare physische Thread angetroffen wird.
Computersystem nach Anspruch 28, ferner umfassend eine Thread-Management-Tabelle zum Speichern von Thread-Information, die zur Identifizierung eines Zustands, eines oder mehrerer Triggerereignisse und eines linearen Anweisungszeigers für jeden der Mehrzahl von logischen Threads dient.
Computersystem nach Anspruch 28, wobei die Thread-Information ferner zur Identifizierung eines Ressourcenerfordernisprofils für jeden der Mehrzahl von logischen Threads dient.
Computersystem nach Anspruch 28, wobei die Mehrzahl der logischen Threads größer als die Mehrzahl der gleichzeitigen physischen Threads sein soll.
Computersystem nach Anspruch 28, wobei die Mehrzahl der logischen Threads kleiner als die Mehrzahl der gleichzeitigen physischen Threads sein soll.