DE10085375B4 - Verfahren und Einrichtung für einen pipeline-verschachtelten Multi-Thread-Befehlsdecodierer - Google Patents

Verfahren und Einrichtung für einen pipeline-verschachtelten Multi-Thread-Befehlsdecodierer Download PDF

Info

Publication number
DE10085375B4
DE10085375B4 DE10085375T DE10085375T DE10085375B4 DE 10085375 B4 DE10085375 B4 DE 10085375B4 DE 10085375 T DE10085375 T DE 10085375T DE 10085375 T DE10085375 T DE 10085375T DE 10085375 B4 DE10085375 B4 DE 10085375B4
Authority
DE
Germany
Prior art keywords
pipeline
instruction
command
valid
thread
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE10085375T
Other languages
English (en)
Other versions
DE10085375T1 (de
Inventor
Jonathan P. Portland Douglas
Daniel J. Hillsboro Deleganes
James D. Portland Hadley
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE10085375T1 publication Critical patent/DE10085375T1/de
Application granted granted Critical
Publication of DE10085375B4 publication Critical patent/DE10085375B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3814—Implementation provisions of instruction buffers, e.g. prefetch buffer; banks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3802—Instruction prefetching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3808—Instruction prefetching for instruction reuse, e.g. trace cache, branch target cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3867—Concurrent instruction execution, e.g. pipeline, look ahead using instruction pipelines

Abstract

Mikroprozessor (201), aufweisend:
einen Befehlsdecodierer (316) zum Decodieren mehrerer Threads eingegebener Befehle in Mikrooperanden, die von einer Ausführungseinheit (318) ausgeführt werden können, wobei der Befehlsdecodierer aufweist:
eine Befehlsdecodierpipeline (400) zum Decodieren jedes eingegebenen Befehls in einen oder mehrere Mikrooperanden, wobei jeder eingegebene Befehl einem der mehreren Threads zugeordnet ist, und
eine parallel zu der Befehlsdecodierpipeline (400) arbeitende Schatten-Pipeline (402), wobei die Schatten-Pipeline jedem Befehl, der gerade in der Befehlsdecodierpipeline decodiert wird, eine Thread-Identifikation und eine Gültig-Anzeige zuordnet,
wobei die Thread-Identifikation und die Gültig-Anzeige verwendet werden, um auf der Ebene jeder Pipelinestufe Lösch-, Taktungs- und/oder Anhalte-Operationen zu steuern,
wobei diejenigen Pipelinestufen, in denen ungültige Befehle enthalten sind, fortgesetzt getaktet werden, bis sie einen gültigen Befehl empfangen, wobei die gültigen Befehle jeweils die ungültigen Befehle überschreiben, womit die ungültigen Befehle aus der Pipeline herausgedrückt werden, und wobei der Takt zu einer einen gültigen Befehl enthaltenden Pipelinestufe...

Description

  • Die vorliegende Erfindung betrifft einen Mikroprozessor mit einem pipeline-verschachtelten Befehlsdecodierer sowie ein Verfahren zum Decodieren mehrerer Threads eingegebener Befehle in Mikrooperanden, die von einer Ausführungseinheit ausgeführt werden können.
  • Grundlegende Befehlsdecodierer und Befehldecodiertechniken, die bei zentralen Prozessoren und Mikroprozessoren verwendet werden, sind gut bekannt. Mit Fortschritten bei dem Entwurf wurden Befehlsdecodierer komplizierter, so daß sie nicht nur Pipeline-Register zum Verarbeiten der Befehle in einer Sequenz enthalten, sondern auch Puffer zum vorübergehenden Speichern vorläufig decodierter Befehle, während weitere Befehle fortgesetzt verarbeitet werden. Jedoch haben die Puffer eine begrenzte Tiefe und können derart gefüllt werden, daß keine weiteren Befehle in ihnen gespeichert werden können. Bei bekannten Prozessoren würde dann, wenn ein Puffer voll wird, die gesamte Befehlsdecodierpipeline steckenbleiben oder anhalten (stall). Ein Anhalten (stall) kann auch aus anderen Gründen bei einem Mikroprozessor auftreten, wenn ein Subsystem nicht in der Lage ist, die Datendurchsatzmenge, die ihm durch vorhergehende Subsysteme zur Verfügung gestellt wird, so zu behandeln, daß keine Daten verlorengehen. Im wesentlichen wird eine Befehlsdecodierpipeline angehalten (stalled), wenn keine weiteren Befehle in der Befehlsdecodierpipeline decodiert werden können.
  • Darüber hinaus war bei Prozessoren des Standes der Technik dann, wenn ein Befehl in der Befehlsdecodierpipeline veraltet und ungültig geworden ist, wie beispielsweise aus einem Cache-Kohärenzproblem heraus, ein Löschen erforderlich. Das Löschen macht die Befehle im wesentlichen ungültig, so daß sie unberücksichtigt bleiben und durch gültige Befehle überschrieben werden können. Bei bekannten Prozessoren werden sämtliche Befehle, einschließlich der gültigen Befehle, in der Befehlsde codierpipeline auf globaler Grundlage gelöscht (d. h., ungültig gemacht). In diesen Fällen müssen gültige Befehle, welche gelöscht worden sind, zurück in den Beginn der Befehlsdecodierpipeline eingegeben werden, um den Decodierprozeß erneut zu starten. Ein solches globales Löschen führt dazu, den Ausführungsprozeß zu verzögern, wenn ein veralteter oder ungültiger Befehl in der Pipeline bekannter Prozessoren auftritt.
  • Bei Prozessoren ist die Verringerung des Energieverbrauchs ein wichtiger Aspekt. Um bei bekannten Prozessoren Energie einzusparen, wird bei vollständigen Funktionsblöcken der synchronen Schaltungen in der Ausführungseinheit der Takt AUS-geschaltet. Das heißt, die Taktsignale werden über vollständige Funktionsblöcke hinweg in einen stabilen Zustand gesetzt. Um dies auszuführen, wurde eine bekannte Herunterschalt(Powerdown)-Steuerlogik verwendet, um zu bestimmen, wann ein vollständiger Funktionsblock untätig ist und dessen Takte ausgeschaltet werden können. Indem die Takte zu den synchronen Schaltungen AUS-geschaltet werden, verändern Signale, einschließlich des Taktsignals, ihren Zustand nicht. In diesem Fall ist es nicht mehr erforderlich, daß Transistoren Kapazitäten auf- oder entladen, die den Signalleitungen zugeordnet sind, und folglich wird Energie eingespart. Da jedoch die Takte über die vollständigen Funktionsblöcke hinweg AUS-geschaltet werden, mußten bekannte Prozessoren warten, bis sämtliche Funktionen in derartigen Blöcken abgeschlossen sind. Dies veranlaßt die bekannten Prozessoren, die Takte zu den Funktionsblöcken selten AUS-zuschalten, so daß über die Zeit wenig Energie eingespart wird.
  • Aus dem US-Patent 5,890,008 ist ein System bzw. Verfahren zum dynamischen Umkonfigurieren eines Prozessors zwischen Ein-Prozessor- und ausgewählten Multi-Prozessor-Konfigurationen bekannt. Es wird eine Prozessorarchitektur beschrieben, die die Hardware eines Prozessors derart anpassen kann, daß sie mehrere parallel ablaufende Anwendungen auf einem einzigen Chip unterstützt. Der beschriebene Prozessor kann dynamisch derart umkonfiguriert werden, daß er einen oder mehrere virtuelle Prozessoreinheiten ("strengths") aufweist. Es werden Prozessoreinheiten, wie beispielsweise eine Befehlsabrufeinheit, eine Befehlsumbenennungseinheit, eine Befehlseinplaneinheit und eine Befehlsausführungseinheit sowie weitere Einheiten beschrieben. Diese Einheiten können sowohl Pipelinestufen enthalten als auch zusammen eine Pipeline bilden. Es wird auch die Ausführung von Befehlen, die verschiedenen Threads angehören, beschrieben. Zu diesem Zweck enthalten einige Einheiten Speicherorte, in denen in Zuordnung zu den Befehlen Thread-Identifikationen gespeichert werden können.
  • Aus dem US-Patent 5,778,246 ist es bekannt, Attribut-Bits, welche ein Gültig-Bit umfassen, durch Stufen einer Decodierpipeline zusammen mit dem zugehörigen Befehl hindurchzutakten.
    •
  • Aufgabe der vorliegenden Erfindung ist es, einen Mikroprozessor mit einem Befehlsdecodierer, der eine Befehlsdecodierpipeline mit mehreren Stufen enthält, zu schaffen, der eine effizientere Behandlung von Stall-Operationen und eine höhere Energieeinsparung durch selektives Herunterschalten der Taktung ermöglicht.
  • Diese Aufgabe wird erfindungsgemäß durch einen Mikroprozessor mit den Merkmalen des Anspruchs 1 bzw. ein Verfahren zum Decodieren mehrerer Threads von einem Befehlsdecodierer eingegebenen Befehlen in Mikrooperanden, die von einer Ausführungseinheiten ausgeführt werden können, mit den Merkmalen des Anspruchs 20 gelöst.
  • Vorteilhafte und/oder bevorzugte Weiterbildungen der Erfindung sind in den Unteransprüchen gekennzeichnet.
    •
  • Im folgenden wird die Erfindung anhand von in den Zeichnungen dargestellten bevorzugten Ausführungsbeispielen näher beschrieben.
  • 1 veranschaulicht eine Blockdarstellung eines typischen Computers, bei welchem die vorliegende Erfindung benutzt wird.
  • 2 veranschaulicht eine Blockdarstellung einer typischen zentralen Verarbeitungseinheit, bei welcher die vorliegende Erfindung benutzt wird.
  • 3 veranschaulicht ein Blockschaltbild eines Mikroprozessors einschließlich des pipeline-verschachtelten Multi-Thread-Befehlsdecodierers gemäß der vorliegenden Erfindung.
  • 4 veranschaulicht eine Blockdarstellung des pipelineverschachtelten Multi-Thread-Befehlsdecodierers.
  • 5 veranschaulicht eine Blockdarstellung der Befehlsdecodierpipeline des Befehlsdecodierers gemäß 4.
  • 6 veranschaulicht ein Blockschaltbild der Schatten-Pipeline und Steuerlogik zum Löschen, Anhalten (stall) und Herunterschalten (powerdown) einer Pipelinestufe für die Befehlsdecodierpipeline gemäß 5.
  • 7 veranschaulicht Steueralgorithmusgleichungen für eine Steuerlogik des Befehlsdecodierers gemäß 4.
  • 8 veranschaulicht ein Taktzeitdiagramm für ein Beispiel eines "Blase-Zusammendrückens" (bubble squeeze), welches durch den Befehlsdecodierer gemäß der vorliegenden Erfindung ausgeführt werden kann.
  • 9 veranschaulicht ein Taktzeitdiagramm für ein Beispiel eines nicht-blockierenden Anhaltens (non-blocking stall), welches von dem Befehlsdecodierer gemäß der vorliegenden Erfindung ausgeführt werden kann.
  • 10 veranschaulicht ein Taktzeitdiagramm für ein Beispiel eines thread-spezifischen Löschens, welches durch den Befehlsdecodierer gemäß der vorliegenden Erfindung ausgeführt werden kann.
  • 11A veranschaulicht ein Taktzeitdiagramm für ein erstes Beispiel eines opportunistischen Herunterschaltens (opportunistic powerdown), welches durch den Befehlsdecodierer der gemäß vorliegenden Erfindung ausgeführt werden kann.
  • 11B veranschaulicht ein Taktzeitdiagramm für ein zweites Beispiel eines opportunistischen Herunterschaltens, welches durch den Befehlsdecodierer gemäß der vorliegenden Erfindung ausgeführt werden kann.
  • In der folgenden detaillierten Beschreibung der vorliegenden Erfindung werden zahlreiche spezielle Details angegeben, um ein besseres Verständnis der vorliegenden Erfindung zu erreichen. Für einen Fachmann ist es jedoch klar, daß die vorliegende Erfindung auch ohne diese speziellen Details ausgeführt werden kann. An anderen Stellen werden gut bekannte Verfahren, Prozeduren, Komponenten und Schaltungen nicht im Detail beschrieben, um Aspekte der vorliegenden Erfindung nicht unnötigerweise zu verdecken.
  • Die Erfindung schafft einen Algorithmus zum Takten, Löschen und Anhalten (stall) eines mehrfädigen (multi-threaded) pipeline-verschachtelten Befehlsdecodierers eines mehrfädigen Systems, der die Leistungsfähigkeit auf ein Maximum bringt und den Energieverbrauch minimiert. Ein Thread (Faden) ist ein Prozeß eines Software-Stückes, der ausgeführt werden kann. Software-Compiler können einen Teil eines Software-Programms kompilieren und ihn in mehrere parallele Ströme ausführbaren Befehlscodes aufteilen oder können mehrere verschiedene Programme gleichzeitig ausführen. Jeder der mehreren parallelen Ströme ausführbaren Codes ist ein Thread. Mehrere Threads können parallel ausgeführt werden, um ein Multitasking zur Verfügung zu stellen oder um die Leistungsfähigkeit zu erhöhen. Die vorliegende Erfindung schafft die Befehlsdecodierpipeline und eine Schatten-Pipeline von Befehls-Thread-Identifikations-(Thread-ID-) und Befehl-Gültig-Bits, welche einen Schatten der Befehlsdecodierpipeline bildet. Die Thread-ID- und Gültig-Bits werden verwendet, um das Löschen (Clear), Takten (clock) und Anhalten (stall) auf der Ebene jeder Pipelinestufe zu kontrollieren. Befehle, die einem Thread zugeordnet sind, können gelöscht oder, in einigen Fällen, angehalten werden, ohne Befehle eines anderen Threads in der Decodierpipeline zu beeinflussen. Bei der vorliegenden Erfindung werden Pipelinestufen (pipe stages) nur dann getaktet, wenn ein gültiger Befehl bereit ist voranzuschreiten, so daß der Energieverbrauch und das Anhalten (stalling) minimiert werden. Ein gültiger Befehl ist ein Befehl, von dem festgestellt wird, daß er durch eine Ausführungseinheit ausführbar ist. Ein ungültiger Befehl ist ein Befehl, der als nicht ausführbar bestimmt worden ist oder ein Befehl, der fehlge schlagen ist oder eine Ausnahmebedingung aufweist, welche erfordert, daß er nicht ausgeführt wird.
  • Es wird jetzt auf 1 Bezug genommen, in der eine Blockdarstellung eines typischen Computers 100 veranschaulicht ist, bei welchem die vorliegende Erfindung benutzt wird. Der Computer 100 enthält eine zentrale Verarbeitungseinheit (CPU) 101, Eingabe/Ausgabe-Peripherieeinrichtungen 102, wie beispielsweise Tastatur, Modem, Drucker, externe Speichereinrichtungen und dergleichen, und Überwachungseinrichtungen 103, wie beispielsweise eine Kathodenstrahlröhren- oder Grafikanzeige. Die Überwachungseinrichtungen 103 stellen Computerinformationen in einem für einen Menschen verständlichen Format, wie beispielsweise einem visuellen oder Audioformat, zur Verfügung.
  • Es wird jetzt auf 2 Bezug genommen, in der eine Blockdarstellung einer typischen zentralen Verarbeitungseinheit 101 veranschaulicht ist, in welcher die vorliegende Erfindung benutzt wird. Die zentrale Verarbeitungseinheit 101 enthält einen Mikroprozessor 201, der die vorliegende Erfindung enthält, eine Plattenspeichereinrichtung 203 und einen Speicher 204 zum Speichern von miteinander gekoppelten Programmbefehlen. Die Plattenspeichereinrichtung 203 kann ein Diskettenlaufwerk, eine Zip-Platte, eine DVD-Platte, eine Festplatte, eine wiederbeschreibbare optische Platte, ein Flash-Speicher oder eine andere, nicht-flüchtige Speichereinrichtung sein. Der Mikroprozessor 201 und die Plattenspeichereinrichtung 203 können Informationen in den Speicher 204 über den Speicherbus 205 sowohl lesen als auch schreiben. So können sowohl der Mikroprozessor 201 als auch die Plattenspeichereinrichtung 203 Speicherplätze in dem Speicher 204 während der Programmausführung ändern. Damit die Plattenspeichereinrichtung 203 dies direkt ausführen kann, enthält sie eine Plattensteuereinrichtung mit einem direkten Speicherzugriff, welche Speicheroperationen in den Speicher ausführen und dadurch Befehlscode modifizieren kann. Da die Steuereinrichtung direkt auf den Speicher zugreifen kann, ist sie ein Beispiel eines Direktspeicherzugriffs(DMA)-Teilnehmers. Andere Einrichtungen, die einen direkten Zugriff zum Speichern von Informationen in den Speicher haben, sind ebenfalls DMA-Teilnehmer. Der Speicher 204 ist üblicherweise ein dynamischer Speicher mit wahlfreiem Zugriff (DRAM), kann aber auch von anderer Art eines wiederbeschreibbaren Speichers sein. Der Speicher kann hier auch als Programmspeicher bezeichnet werden, da er benutzt wird, um Programmbefehle zu speichern. Bei anfänglicher Ausführung eines in der Plattenspeichereinrichtung 203 oder in irgendeiner anderen Quelle, wie beispielsweise den I/O-Einrichtungen 102 gespeicherten Programms, liest der Mikroprozessor 201 die in der Plattenspeichereinrichtung 203 oder den anderen Quellen gespeicherten Programmbefehle und schreibt sie in den Speicher 204. Es werden eine oder mehrere Seiten oder Bruchteile davon der in dem Speicher 204 gespeicherten Programmbefehle durch den Mikroprozessor 201 gelesen (d. h., "abgerufen), vorläufig decodiert und in einen (in 2 nicht gezeigten) Befehls-Cache zur Ausführung gespeichert. Einige der in dem Befehls-Cache gespeicherten Programmbefehle können in eine (in 2 nicht gezeigte) Befehlspipeline zur Ausführung durch den Mikroprozessor 201 gelesen werden.
  • Es wird jetzt auf 3 Bezug genommen, in der eine Blockdarstellung des Mikroprozessors 201 veranschaulicht ist, der mit dem Speicher 204 über den Speicherbus 205 gekoppelt ist. Der Mikroprozessor 201 enthält einen Nächster-Befehl-Prozessor (IP) 310, einen Befehlsübersetzungsnachschlagepuffer (ITLB; instruction translation lookaside buffer) 312, eine Speichersteuereinrichtung 313, einen Spur-Befehl-Cache (trace instruction cache) 314, einen Spur-Nächster-Befehl-Prozessor (IP) (trace next instruction processor) 315, einen Befehlsdecodierer 316, eine Ausführungseinheit 318 und eine Abschlußeinheit (retirement unit) 320. Die Befehlsspeicherelemente in dem Befehlsdecodierer 316, der Spur-Cache 314, die Ausführungseinheit 318, die Retirement-Einheit 320 und andere Befehlsspeicherelemente werden als Befehlspipeline des Mikroprozessors angesehen. Der Nächster-Befehl-Prozessor (IP) 310 veranlaßt, daß der nächste Satz von Befehlen eines Prozesses aus dem Speicher 204 abgerufen, durch den Befehlsdecodierer 316 decodiert und in den Spur-Cache 314 gespeichert wird. Der Mikroprozessor 201 ist vorzugsweise eine mehrfädige (multi-threaded) Maschine. Das heißt, mehrere Threads von Befehlen können von dem Mikroprozessor 201 decodiert und ausgeführt werden, um ein Multitasking zu unterstützen.
  • Der Befehlsübersetzungsnachschlagepuffer (ITLB) 312 enthält Seitentabellen-Adreßübersetzungen aus linearen in physikalische Adressen in den Speicher 204, um einen virtuellen Speicher zu ermöglichen. Die Seitentabellen-Adreßübersetzungen ordnen die in dem physikalischen Speicher 204 gespeicherten Befehle den in dem Spur-Befehls-Cache 314 gespeicherten Befehlen zu. Im allgemeinen akzeptiert der ITLB 312 eine eingegebene lineare Adresse und gibt eine dem Ort der Befehle in dem Speicher 204 zugeordnete physikalische Adresse zurück.
  • Der Spur-Befehls-Cache 314 kann mehrere Sequenzen oder Spuren (traces) decodierter Befehle für verschiedene Programme speichern, um ein Multitasking zur Verfügung zu stellen. Bei einem Spur-Befehls-Cache ist nur dem ersten Befehl einer Serie von Befehlen für ein Programm (einer "Spur") eine Adresse zugeordnet. Eine Sequenz von zueinander in Beziehung stehenden Befehlen, die in dem Spur-Befehls-Cache gespeichert ist, wird oftmals als "Spur" von Befehlen bezeichnet. Die weiteren Befehle, die dem ersten Befehl folgen, werden einfach in dem Cache ohne zugeordnete externe Adresse gespeichert. Der Spur-Befehls-Cache 314 kann Befehle enthalten, die von der Ausführungseinheit 318 verwendet werden können, um irgendeine Funktion oder einen Prozeß auszuführen. Wenn die Funktion oder der Prozeß einen Befehl erfordert, der sich nicht in dem Befehls-Cache 314 befindet, tritt ein Fehlversuch auf, und der Befehl muß aus dem Speicher 204 abgerufen werden. Die Speichersteuereinrichtung 313 bildet gewöhnlich eine Schnittstelle zu dem Befehls-Cache 314, um hier Befehle zu speichern. Im Falle eines Fehlversuchs ruft die Speichersteuereinrichtung 313 den gewünschten Befehl aus dem Speicher 204 ab und stellt ihn dem Spur-Befehls-Cache 314 über den ITLB 312 und den Befehlsdecodierer 316 zur Verfügung.
  • Es wird jetzt auf 4 Bezug genommen, in der ein Blockschaltbild des pipeline-verschachtelten Multi-Thread-Befehlsdecodierers 316 gemäß der vorliegenden Erfindung veranschaulicht ist. Der Befehlsdecodierer 316 enthält eine Befehlsdecodierpipeline 400, Steuerlogik 401 und eine Schatten-Pipeline 402. Der Befehlsdecodierer 316 unterstützt ein Multi-Threading von Befehlen. Grundsätzlich akzeptiert die Befehlsdecodierpipeline 400 des Befehlsdecodierers 316 einen Block von Befehlen/Operanden an ihrem Eingang, trennt diesen Block in vollständig einzelne Befehle/Operanden auf, decodiert jeden Befehl/Operanden und führt die erforderliche Befehlsverarbeitung durch, die benötigt wird, um ihn in einen Mikrooperanden (UOP) umzuformen, welcher verständlich ist und durch einen Ausführungseinheit, wie beispielsweise die Ausführungseinheit 318, ausgeführt werden kann. Die UOPs, die von dem Befehlsdecodierer 316 ausgegeben werden, werden in den Spur-Befehls-Cache 314 für eine vorübergehende Speicherung vor der Ausführung eingekoppelt. Generell enthält die Befehlsdecodierpipeline 400 eines oder mehrere Register R1-RN, einen oder mehrere Puffer B1-BP und eine oder mehrere Logikstufen L1-LO, die zwischen den Registern R1-RN und den Puffern B1-BP eingestreut sind. Die Register R1-RN können aus D-Flip-Flops der transparenten Latch-Speichern mit entsprechend geeigneten Taktsignalen bestehen. Die Logikstufen L1-LO führen die Decodierung und erforder liche Befehlsverarbeitung von Operanden durch, um UOPs zu bilden. Während der Puffer BP in 4 als der Befehlsdecodierpipeline 400 zugeordnet gezeigt ist, kann er statt dessen als Teil eines Befehls-Cache angesehen werden.
  • Einem in die Befehlsdecodierpipeline 400 eingegebenen Befehl sind ein Befehls-Thread-ID und ein Befehl-Gültig-Bit zugeordnet. Die Schatten-Pipeline 402 enthält eine Pipe für den Befehls-Thread-ID, um ein Multi-Threading zu unterstützen, und eine Pipe für das Befehl-Gültig-Bit. Bei dem bevorzugten Ausführungsbeispiel ist der Befehls-Thread-ID ein Einzelbit oder ein Kennzeichen (Token), das einen abweichenden Befehls-Thread gegenüber dem Thread zuvor und dem Thread danach in der Befehlsdecodierpipeline darstellt. Bei dem bevorzugten Ausführungsbeispiel bezieht sich ein Einzelbit oder Token auf eine Thread-Identifikation Null (Id0) und eine Thread-Identifikation Eins (Id1). Mehrere Bits können verwendet werden, um eine ausgeklügeltere Multi-Thread-Identifikation zur Verfügung zu stellen, um eine kompliziertere Befehlspipeline zu unterstützen. Die Gültig-Bits und die Thread-Identifikations-Bits können darüber hinaus gemeinsam codiert werden, was wiederum die Befehl-Gültig-Bit-Pipeline mit der Befehls-Thread-ID-Pipeline der Schatten-Pipeline miteinander verschmilzt. Der Befehls-Thread-ID und das Befehl-Gültig-Bit fließen durch die Schatten-Pipeline 402 parallel zu jedem durch die Befehlsdecodierpipeline decodierten Befehl. Damit die Schatten-Pipeline 402 dies ausführen kann, spiegelt sie die Befehlsspeicherelemente (Register, Puffer, etc.) der Befehlsdecodierpipeline 400, indem sie Register R1'-RN' und Puffer B1'-BP' für den Befehls-Thread-ID und das Befehl-Gültig-Bit einschließt. Die Register R1'-RN' und die Puffer B1'-BP' stellen die gleichen Speicherelemente zur Verfügung wie R1-RN und B1-BP, die sich in der Befehlsdecodierpipeline 400 finden. Die Register R1'-RN' und die Puffer B1'-BP' können aus D-Flip-Flops oder transparenten Latch-Speichern mit geeigneten Taktsignalen bestehen, um mit den Registern R1-RN übereinzustimmen. Die Schatten-Pipeline 402 benötigt nicht die Logikstufen L1-LO, die einen Befehl von einer Pipelinestufe zur nächsten ändern können. Der Befehls-Thread-ID und das Befehl-Gültig-Bit werden von einer Pipelinestufe zur nächsten durch die Latch-Speicher/Register und Puffer parallel zur Befehlsverarbeitung weitergeleitet, während die Steuerlogik 401 jeden/jedes liest. Die Steuerlogik 401 stellt Taktsignale an die Register R1-RN und R1'-RN' und die Puffer B1-BP und B1'-BP' zur Verfügung. Das gleiche Taktsignal wird jedem Befehlsspeicherelement (Register, Puffer etc.) jeweils in der Befehlsdecodierpipeline 400 und der Schatten-Pipeline 402 zur Verfügung gestellt. Anhalten (stalls) und opportunistisches Herunterschalten (opportunistic power down) gemäß der vorliegenden Erfindung beeinflußt in gleicher Weise die Taktung der Befehlsdecodierpipeline und die der Schatten-Pipeline. Während 4 die Befehlsdecodierpipeline 400 als von der Schatten-Pipeline aus Gründen der Klarheit getrennt veranschaulicht, können sie als eine Pipeline, die durch das gleiche Taktsignal getaktet wird, integriert sein. In diesem Fall werden das Befehl-Gültig-Bit und der Befehls-Thread-ID miteinander parallel zu einem Befehl in einer Pipeline gehalten, wenn der Befehl durch jede Pipelinestufe der Pipeline hindurch decodiert wird. Das Befehl-Gültig-Bit und der Befehls-Thread-ID können mit dem Befehl auf irgendeine Weise codiert werden, damit sie während des Befehlsdecodierprozesses zusammengehalten werden.
  • Bei Verwendung eines Einzelbits als Thread-ID unterstützt die vorliegende Erfindung ein Multi-Threading, indem sie es Befehlen verschiedener Threads gestattet, miteinander in der Befehlsdecodierpipeline 400 zwischen jeder Pipelinestufe gemischt zu sein. Bei Verwendung mehrerer Bits als Thread-ID kann die vorliegende Erfindung so geändert werden, daß sie eine erhöhte Komplexität und zusätzliche Hardware aufweist, welche dupliziert sein kann, um mehr als zwei Threads in jeder Pipelinestufe der Decodierpipeline jeweils zu unterstützen. In beiden Fällen kann ein einziger Befehlsdecodierer verwendet werden, um mehrerer Threads zu unterstützen.
  • Es wird jetzt auf 5 Bezug genommen, in der eine detaillierte Blockdarstellung der Befehlsdecodierpipeline 400' des Ausführungsbeispiels offenbart wird. Bei dem bevorzugten Ausführungsbeispiel besteht der Satz von Befehlen oder Operanden zumeist aus Intel-X86-Befehlen, welche mit Software rückwärtskompatibel sind, in Kombination mit weiteren speziellen Befehlen oder Operanden, die von fortgeschritteneren Intel-Mikroprozessoren unterstützt werden. Bei dem bevorzugten Ausführungsbeispiel sind die Befehle oder Operanden INTEL-X86-Befehle, welche mit Software rückwärtskompatibel sind und in UOPs decodiert werden, welche von einer fortgeschrittenen Ausführungseinheit, der Ausführungseinheit 318, ausgeführt werden können. Die Befehlsdecodierpipeline 400' empfängt diese Befehle oder Operanden aus einem (nicht gezeigten) Puffer und konvertiert sie in UOPs, welche durch die Ausführungseinheit 318 ausgeführt werden können. Indem er damit fortfährt, Intel-X86-Befehle zu decodieren, behält der Mikroprozessor 201 eine Software-Rückwärtskompatibilität.
  • Die Befehlsdecodierpipeline 400' bei dem bevorzugten Ausführungsbeispiel weist sieben Befehlsspeicherelemente auf, die für einen zu decodierenden Befehl sieben Taktzyklen verwendet und am Ende der Pipeline einen UOP erzeugt. Jedoch kann die Befehlsdecodierpipeline 400' eine abweichende Anzahl von Speicherelementen aufweisen, die eine abweichende Länge zur Verfügung stellt, vorausgesetzt, die Schatten-Pipeline 402 weist eine übereinstimmende Anzahl von Speicherelementen auf, so daß der Befehls-Thread-ID und das Befehl-Gültig-Bit parallel zu dem Befehl sind, wenn dieser verarbeitet wird. Bei dem bevorzugten Ausführungsbeispiel kann die Befehlsdecodierpipeline mehrere Threads sequentiell verarbeiten, wobei jeweils ein Thread in einer Pipelinestufe zu einem gegebenen Zeitpunkt decodiert wird.
  • Die Befehlsspeicherelemente innerhalb der Befehlsdecodierpipeline 400' umfassen fünf Register 501A-501E zwischen Logikblöcken und zwei Puffer 502A und 502B. Die Register 501A-501E können aus D-Flip-Flops oder transparenten Latch-Speichern mit entsprechend geeigneten Taktsignalen bestehen. Die Puffer 502A und 502B sind Datenpuffer zum Speichern einer Mehrzahl von Datenbytes. Bei dem bevorzugten Ausführungsbeispiel umfaßt die Logikfunktionalität in der Befehlsdecodierpipeline 400' einen ersten Längendecodierer 511, einen zweiten Längendecodierer 512, einen Befehlsausrichter 513, einen Fehler/Präfix-Detektor und Feld-Lokator/Extraktor 514, einen Befehlsübersetzer 515, einen Befehls-Aliaser 516 und einen UOP-Versender (-Dispatcher) 517.
  • Bei dem bevorzugten Ausführungsbeispiel sind die Puffer 502A und 502B thread-spezifische Puffer. Im wesentlichen bilden die Puffer 502A und 502B zwei Unterbrechungspunkte in der Befehlsdecodierpipeline 400, da sie ihre Inhalte bei variablen Raten ausgeben (d.h., sich entleeren) können. Der Puffer 502A findet sich zwischen dem zweiten Längendecodierer 512 und dem Befehlsausrichter 513. Der Puffer 502B findet sich am Ende der Befehlsdecodierpipeline 400 und kann als Teil des Spur-Befehls-Cache 314 betrachtet werden. Jedoch ist er als Teil der Befehlsdecodierpipeline 400 gezeigt, um das vollständige Problem, das die vorliegende Erfindung löst, zu verstehen. Bei dem bevorzugten Ausführungsbeispiel sind die Register 501A-501E D-Flip-Flops, die jeweils in einem anderen Zyklus als das nächste getaktet werden.
  • Der in die Befehlsdecodierpipeline 400' eingegebene Befehl 410 kann ein sehr langes Befehlswort (VLIW; very long instruction word) sein. Der VLIW-Eingabebefehl 410 wird in den ersten Längendecodierer 511 und den zweiten Längendecodierer 512 eingegeben, decodiert und in die mehreren Prozesse oder Funktionen (d. h., Befehle) aufgetrennt und in den Puffer 502A gespeichert. Bei dem bevorzugten Ausführungsbeispiel akkumuliert der Puffer 502A X86-Befehle voller oder partieller variabler Länge. Puffer 502B am Ausgang der Befehlsdecodierpipeline 400' wird verwendet, um eine fest vorgegebene Anzahl von UOPs zu akkumulieren, die die Befehlsdecodierpipeline 400' verlassen, bevor sie in den Spur-Cache (trace cache) 314 gespeichert werden. Wenn ein Puffer voll wird, d. h., wenn ein Puffer nicht in der Lage ist, weitere Befehle aufzunehmen, benötigt die Befehlsdecodierpipeline 400' ein Anhalten (stall), um zu vermeiden, daß Befehle verlorengehen. Jeder der Puffer 502A und 502B kann ein Stall-Signal mit dem Thread-ID des Stall erzeugen, um die Befehlsdecodierpipeline 400' anzuhalten.
  • Wenn erforderlich, kann der Puffer 502B zusätzlich ein Latch-Signal mit dem Lösch-Thread-ID-erzeugen, so daß Befehle in der Befehlsdecodierpipeline 400' ungültig gemacht werden, die dem Lösch-Thread-ID zugeordnet sind. Löschsignale mit Lösch-Thread-IDs können darüber hinaus aus vorhergehenden Verarbeitungsblöcken oder nachfolgenden Verarbeitungsblöcken in dem Mikroprozessor dem Befehlsdecodierer von außen zugeleitet werden. Der Fehler/Präfix-Detektor und Feld-Lokator/Extraktor 514 kann ebenfalls Löschsignale mit den Lösch-Thread-Ids erzeugen, wenn er feststellt, daß ein Befehl ungültig ist, welcher unabhängig von der weiter erforderlichen Decodierung nicht von der Ausführungseinheit 118 ausgeführt werden kann. Darüber hinaus kann der Fehler/Präfix-Detektor und Feld-Lokator/Extraktor 514 zusätzliche Zyklen benötigen, um seine Feststellung zu einem gegebenen Befehl zu treffen. In diesem Fall kann der Fehler/Präfix-Detektor und Feld-Lokator/Extraktor 514 ein Anhalte(stall)-Signal mit dem Thread-ID des Anhaltens ausgeben.
  • Puffer 502A, der als Lenkungspuffer (steering buffer) bezeichnet wird, hält die mehreren Prozesse oder Funktionen (d. h., Befehle) des VLIW-Eingabebefehls 410 für einen gegebenen Thread, der einen gegebenen Thread-ID aufweist. Bei dem bevorzugten Ausführungsbeispiel wird der in die Befehlsdecodierpipeline 400' eingegebene Befehl 410 dem Puffer 502A in 8-Byte-Chunks von Befehlen zur Verfügung gestellt. Während der Puffer 502A drei 8-Byte-Chunks Befehle in drei 8-Byte-Registern, die 24 Bytes Informationen parallel zur Verfügung stellen, aufnehmen und halten kann, wird jeweils ein Befehl an seinem Ausgang zur Verfügung gestellt. Bei dem bevorzugten Ausführungsbeispiel gibt der Puffer 502A vollständige Intel-X86-Befehle aus. Intel-X-86-Befehle, die von dem Puffer 502A erzeugt werden, können zwischen 1 und 15 Bytes lang sein. Aufgrund dieser variablen Länge der Intel-X86-Befehle kann es sein, daß Daten mit einer stark abweichenden Rate von dem Puffer 502 empfangen bzw. von ihm ausgegeben werden. Der Puffer 502A hält denselben Chunk von Befehlen in einem gegebenen 8-Byte-Register, bis sämtliche Befehle, die von diesem Register bedient werden, verarbeitet sind. Das heißt, es könnten für jedes in den Puffer 502A geschriebene 8-Byte-Chunk von Befehlen acht Zyklen erforderlich sein, um einen Befehl auszulesen, es könnte einen Zyklus beanspruchen, um einen Befehl auszulesen, oder der Puffer könnte gezwungen sein, darauf zu warten, daß ein weiterer oder weitere 8-Byte-Chunks von Befehlen empfangen werden, um einen Befehl an seinem Ausgang abzuschließen. Folglich könnte in einem Falle ein 8-Byte-Register im Puffer 502A frei werden, während in einem anderen Fall die drei 8-Byte-Register im Puffer 502A alle gleichzeitig frei werden. Die mehreren Prozesse oder Funktionen (d. h., Befehle) des VLIW-Eingabebefehls 410 werden von dem Puffer 502A als Befehle 410' in der Weise eines FIFO ähnlich einem Schieberegister ausgegeben. Multiplexer können verwendet werden, um den Prozeß oder die Funktion der Mehrzahl von Prozessen oder Funktionen auszuwählen, der bzw. die in dem Puffer 502A für einen gegebenen VLIW-Eingabebefehl 410 gespeichert ist, so daß ein tatsächliches Schieberegister nicht implementiert zu werden braucht. Die von dem Multiplexprozeß ausgewählten Ausgabebefehle 410' werden dem Befehlsausrichter 513 zur Verfügung gestellt. Da die Befehle 410' für denselben Thread ausgegeben werden, wird der Thread-ID für jeden ausgegebenen Befehl dupliziert, bis der Thread von Befehlen abgeschlossen oder aus dem Puffer 502A gelöscht ist. Puffer 502A signalisiert ein Anhalten (stall) mit einem Thread-ID, bis sämtliche der mehreren in dem Puffer 502A für einen gegebenen Eingabebefehl 410 und Thread gespeicherten Prozesse oder Funktionen an den Befehlsausrichter 513 ausgegeben oder ungültig gemacht (invalidiert) worden sind. Ein von dem Puffer 502A initiiertes Anhalten (stall) kann möglicherweise vorhergehende Pipelinestufen, den ersten Längendecodierer 511 und den zweiten Längendecodierer 512, anhalten. Ein vom Puffer 502A initiiertes Anhalten würde die nachfolgenden Pipelinestufen 513-517 nicht anhalten.
  • Der Puffer 502B hält die von dem UOP-Versender 517 versandten UOPs vor deren Speicherung in dem Spur-Befehls-Cache 314. Deswegen wird der Puffer 502B oftmals als Spur-Cache-Füllpuffer bezeichnet und als Teil des Spur-Cache 314 und nicht als Teil des Befehlsdecodierers 316 angesehen. Wenn der Puffer 502B voll wird, kann ein Anhalten (stall) von dem Puffer 502B initiiert werden. Ein vom Puffer 502B initiiertes Anhalten kann möglicherweise eine oder mehrere der vorhergehenden Pipelinestufen 513 bis 517, den Puffer 502A und frühere Pipelinestufen 511 und 512 anhalten.
  • Wie zuvor beschrieben wurde, decodieren der erste Längendecodierer 511 und der zweite Längendecodierer 512 den Befehl 410 in mehrere Prozesse oder Funktionen (d. h., Befehle), die in dem VLIW enthalten sind, und trennen diese. Der Puffer 502A gibt diesen einen oder die mehreren Prozesse oder Funktionen als Befehle 410' aus. Der Befehlsausrichter 513 richtet die Befehle 410' in geeignete Bitfelder zur weiteren Verarbeitung durch den Befehlsdecodierer aus. Der Fehler/Präfix (fault/prefix)-Detektor und Feld-Lokator/Extraktor 514 bestimmt, ob der decodierte Befehl durch die Ausführungseinheit 318 ausgeführt werden kann. Der Befehlsübersetzer 515 konvertiert X86-Befehle in einen UOP, sofern dies möglich ist. Der Befehls-Aliaser 516 schafft die Möglichkeit eines Aliasing eines Befehls, wodurch die Decodierlogik einfacher gemacht wird. Der UOP-Versender (Dispatcher) 517 gibt UOPs in den Puffer 502B aus. Der UOP-Versender 517 stellt die abschließende Überprüfung dar, um zu bestimmen, ob ihm von der vorhergehenden Befehlspipelinestufe ein gültiger Befehl präsentiert wird.
  • Es wird jetzt auf 6 Bezug genommen, in der ein detailliertes Blockschaltbild der Steuerlogik 401 und Schatten-Pipeline 402 veranschaulicht ist. Die Schatten-Pipeline 402 umfaßt die Befehl-Gültig-Schatten-Pipeline 601 und die Thread-Identifikations-Schatten-Pipeline 602. Die in 6 veranschaulichte Steuerlogik 401 umfaßt die Herunterschaltlogik 603, die Taktsteuerlogik 604, die Löschlogik 605A bis 605M, jeweils eine für jede der M Pipelinestufen, und die Thread-Auswahl-Multiplexer 606A bis 606M, jeweils einen für jede der M Pipelinestufen. Die Befehl-Gültig-Schatten-Pipeline 601 umfaßt M zurücksetzbare D-Latch-Speicher/Flip-Flops 611A bis 611M, die in der in 6 gezeigten Weise miteinander in Serie gekoppelt sind, jeweils eines für jede Pipelinestufe. Die Thread-Identifikations-Schatten-Pipeline 602 umfaßt M D-Latch-Speicher/Flip-Flops 612A bis 612M, jeweils eines für jede Pipelinestufe, die in Reihe gekoppelt sind, wie es in 6 gezeigt ist. Die Latch-Speicher/Flip-Flops 611A bis 611M und Latch-Speicher 612A bis 612M können aus D-Flip-Flops oder transparenten Latch-Speichern mit entsprechenden geeigneten Taktsignalen bestehen, so daß sie mit den Registern 501A bis 501E und den Puffern 502A und 502B übereinstimmen. Die Schatten-Pipeline 402 schafft die Mittel, die für mehrere Threads von Befehlen innerhalb derselben Befehlsdecodierpipeline 401 erforderlich sind. Die D-Latch-Speicher/Flip-Flops 611A bis 611M und die D-Latch-Speicher/Flip-Flops 612A bis 612M der Schatten-Pipeline 402 halten das Befehl-Gültig-Bit 416 und den Befehls-Thread-ID 418 jedes Befehls innerhalb jeder Pipelinestufe der Befehlsdecodierpipeline 401. Bei dem bevorzugten Ausführungsbeispiel ist der Wert von M gleich sieben. Der Abschluß der Decodierung eines Befehls erfordert wenigstens M Takzyklen.
  • Der durch die Steuerlogik 401 gemäß der vorliegenden Erfindung implementierte Steueralgorithmus zum Unterstützen eines Multi-Threading in dem Pipeline-Befehlsdecodierer 400' weist drei funktionelle Hauptteile auf: (1) ein effizientes Anhalten (Stalling) und Bubble Squeezing (Blasen-Zusammendrücken), (2) ein thread-spezifisches Löschen und (3) ein opportunistisches Herunterschalten. Es wird jetzt auf die 6 und 7 Bezug genommen, wobei 7 Steueralgorithmusgleichungen veranschaulicht, die von der erfindungsgemäßen, in 6 veranschaulichten Steuerlogik 401 ausgeführt werden. Die in 6 veranschaulichte Herunterschaltlogik 603 führt die "Herunterschalten für eine Pipelinestufe X"-Gleichung für jede Pipelinestufe aus. Um dies auszuführen, weist die Herunterschaltlogik 603 eine Eingabe des Befehl-Gültig-Bits jeder Pipelinestufe auf. Darüber hinaus führt die Herunterschaltlogik 603 die "Anhalten für vorletzte Pipelinestufe(NLP)"-Gleichung und die "Anhalten für irgendeine andere Pipelinestufe(X)"-Gleichung aus, die in 7 veranschaulicht sind. Um dies ausführen zu können, empfängt die Herunterschaltlogik 603 zusätzlich ein Thread-Anhalt-Signal mit dem Thread-ID des Anhaltens, um zu bestimmen, ob die vorletzte Pipelinestufe der Befehlsdecodierpipeline angehalten werden sollte. Die Herunterschaltlogik 603 verarbeitet die Anhalt-Bedingung für jede Pipelinestufe, indem sie eine UND-Verknüpfung der Befehl-Gültig-Bits einer gegebenen Pipelinestufe mit den Befehl-Gültig-Bits der nachfolgenden Pipelinestufe ausführt und ferner diese Ergebnisse mit der Bestimmung darüber, ob die vorletzte Pipelinestufe angehalten ist, UND-verknüpft. Die Herunterschaltlogik leitet die Anhalt-Bedingung für jede Stufe zu der Taktsteuerlogik 604 weiter. Die Taktsteuerlogik läßt den Takt für jede Pipelinestufe in Übereinstimmung mit der Gleichung für "Taktfreigabe für irgendeine Pipelinestufe X", die in 7 veranschaulicht ist, laufen bzw. hält ihn an. Wenn eine gegebene Pipelinestufe nicht angehalten ist und sie nicht heruntergeschaltet ist, dann ist der Takt der gegebenen Pipelinestufe freigegeben, so daß sie auf dem nächsten Zyklus getaktet werden kann.
  • Die in 6 für jede Pipelinestufe veranschaulichte Löschlogik 605A bis 605M führt die logische Gleichung "Löschen für irgendeine Pipelinestufe X", die in 7 veranschaulicht ist, aus. Bei jeder Pipelinestufe mit Ausnahme der vorletzten wird diese Gleichung ausgewertet um zu bestimmen, ob der Befehl in der parallelen Pipelinestufe der Befehlsdecodierpipeline ungültig gemacht werden sollte, indem das Befehl-Gültig-Bit gelöscht oder gesetzt wird, so daß es einen ungültigen Befehl anzeigt. Die Auswahl-Signale, die den Multiplexern 606A bis 606M eingegeben werden, wählen aus, ob der Takt(X)-Term oder der NICHT-Takt(X)-Term der Lösche(X)-Gleichung berechnet wird, um das Löschsignal für jede Pipelinestufe zu erzeugen. Das aus jedem der Multiplexer 606A bis 606M ausgegebene Löschsignal für jede Pipelinestufe wird mit dem Rücksetzanschluß jedes der rücksetzbaren D-Latches/Flip-Flops 611A bis 611M gekoppelt. Wenn ein Löschsignal für eine gegebene Pipelinestufe erzeugt wird, wird das Befehl-Gültig-Bit gesetzt oder zurückgesetzt, so daß es einen ungültigen Befehl innerhalb der parallelen Pipelinestufe der Befehlsdecodierpipeline anzeigt. Jede Löschlogik 605A bis 605M empfängt als Eingangssignal den Befehl-Thread-ID einer gegebenen Pipelinestufe und den Befehl-Thread-ID der vorhergehenden Pipelinestufe, um die Terme der Lösch(X)-Gleichung zu berechnen. Zusätzlich empfangen sämtliche Löschlogiken 605A bis 605M das Lösche-Threads-Signal mit dem Lösch-Thread-ID.
  • Beispiele der Funktionalität der Algorithmen des effizienten Anhaltens und Bubble Squeezing, des thread-spezifischen Löschens und des opportunistischen Herunterschaltens werden jetzt unter Bezugnahme auf die 8 bis 10, 11A und 11B beschrieben. Die in den 8 bis 10, 11A und 11B angegebenen Veranschaulichungen sind der Steuerung der Befehlsdecodierpipeline 400' zwischen dem Puffer 502A und dem Puffer 502B in 5 zugeordnet. Die Pipelinestufen 513 bis 517 werden in der nachfolgenden Diskussion als Pipelinestufen PS1 bis PS5 bezeichnet, können aber als Steuerung irgendeiner Befehlsdecodierpipeline in einem Befehlsdecodierer, der die Algorithmen der vorliegenden Erfindung verwendet, verallgemeinert werden.
  • Effizientes Anhalten und Bubble Squeezing
  • Ein Anhalten (Stalling) tritt im allgemeinen dann auf, wenn irgendein Subsystem in einem Mikroprozessor keine weiteren Daten aus einem anderen Subsystem handhaben kann. Um ein Verlieren von Daten zu vermeiden, mußten die bekannten Mikroprozessor-Subsysteme angehalten werden. Innerhalb eines Befehlsdecodierers muß ein Anhalten dann auftreten, wenn keine weiteren Befehle durch eine gegebene Pipelinestufe in der Befehlsdecodierpipeline decodiert werden können. Ein blockierendes Anhalten (blocking stall) ist ein Anhalten, das jede Pipelinestufe innerhalb einer Befehlsdecodierpipeline unanhängig von dem Thread-ID oder der Gültigkeit der Befehle in der Pipeline stoppt. Ein nicht-blockierendes Anhalten (non-blocking stall) ist ein Anhalten, welches thread-spezifisch ist oder die Befehl-Gültig-Bits berücksichtigt. Das nicht-blockierende Anhalten berücksichtigt den ID des Threads, welcher angehalten werden soll, und die Gültig-Bits der Pipelinestufe. wenn beispielsweise ein Anhalten bei einem Thread-ID von 1 auftritt und ein Befehl mit einem Thread-ID von 0 ausgeführt wird, könnte der Befehl mit dem Thread-ID von 0 mit der Ausführung fortfahren, und Befehle mit einer Thread-ID von 0 würden fortgesetzt durch den Befehlsdecodierer decodiert werden, bis ein Befehl mit einem Thread-ID von 1 in die Befehlsdecodierpipeline eintritt. Wenn ein Befehl mit einem Thread-ID von 1 in die Befehlsdecodierpipeline eintritt, wird sie angehalten. Ein blockierendes Anhalten berücksichtigt keine Betrachtungen des Thread-ID eines Befehls. Ein effizientes Anhalten ist der durch die vorliegende Erfindung in dem Befehlsdecodierer durchgeführte Algorithmus zum Minimieren des Einflusses irgendeines Anhaltens.
  • Eine Blase (bubble) ist eine Reihe ungültiger Befehle, die in dem Befehlsdecodierer angeordnet sind. Üblicherweise wird die Blase im Ergebnis eines Ungültig-werdens eines vollständigen Threads von Befehlen, der unter weitere Befehls-Threads in der Befehlsdecodierpipeline eingemischt ist, erzeugt. Ein Beispiel, das dies bewirken würde, ist eine fehlverbundene Verzweigung. Der Blasen-Zusammendrück-Algorithmus (Bubble-Squeeze-Algorithmus), der durch die vorliegende Erfindung ausgeführt wird, drückt grundsätzlich die Blasen von Befehlen in der Befehlsdecodierpipeline zusammen. Der Bubble-Squeeze-Algorithmus wird im wesentlichen ausgeführt, indem die Pipelinestufen, in denen die Befehle als ungültig markiert sind, fortgesetzt getaktet werden, bis ein gültiger Befehl empfangen wird. Die Takte zu einer einen gültigen Befehl enthaltenden Pipelinestufe werden vorübergehend gestoppt, bis der Grund für das Anhalten gelöscht ist. Die ungültigen Befehle werden schließlich herausgedrückt, indem gültige Befehle über die in den Pipelinestufen gespeicherten ungültigen Befehle geschrieben werden. Der Bubble-Squeeze-Algorithmus fährt damit fort, die Befehlsdecodierpipeline ablaufen zu lassen, um Befehle der andere Threads die Pipeline hinab zu bewegen, statt ein nicht-intelligentes oder -blockierendes Anhalten auszuführen. Das Blasen-Zusammendrücken (bubble squeezing) kann einen höheren Durchsatz in dem Befehlsdecodierer zur Verfügung stellen.
  • Dieser Algorithmus für ein effizientes Anhalten und Blasen-Zusammendrücken verarbeitet die thread-spezifischen Anhalte-Operationen einschließlich derjenigen, die durch die variablen Verbrauchspuffer (consumption buffers) erzeugt werden. Durch Verwendung des Thread-ID aus der Thread-ID-Pipeline und der Befehl-Gültig-Bits der Befehl-Gültig-Pipeline bestimmt der Algorithmus, ob ein gültiger Befehl des dem Anhalten entsprechenden Thread-ID dem Puffer im nächsten Zyklus präsentiert würde. Wenn dies der Fall ist, dann wird die vorletzte Pipelinestufe vor dem Puffer angehalten (daran gehindert, weitere Befehle auszugeben). Die vorletzte Pipelinestufe wird bei dem bevorzugten Ausführungsbeispiel anstelle der letzten Pipelinestufe verwendet, um eine Zykluszeit der Berechnung zur Verfügung zu stellen. Bei alternativen Ausführungsbeispielen könnte anstelle der vorletzten Pipelinestufe die letzte Pipelinestufe verwendet werden. Irgendwelche weiteren Befehlsdecodierpipelinestufen, die keinen gültigen Befehl haben, werden nicht angehalten. Irgendwelche Befehlspipelinestufen nach dem Puffer werden ebenfalls nicht angehalten. Dies ermöglicht den Befehlen in der Pipeline voranzuschreiten, bis die Pipeline voll ist, während noch die vorletzte Pipelinestufe angehalten bleibt, um ein Verlieren eines Befehls zu vermeiden, was die gesamte Decodierbandbreite erhöht. Wenn die Befehlsdaten, die gerade in den Puffer eintreten, nicht vom gleichen Thread wie das Anhalten sind, dann werden die Takte laufen gelassen. Dies bewahrt die Befehle eines anderen Threads davor, angehalten zu werden, und ermöglicht Befehlen desselben Threads, die weiter zurück in der Befehlsdecodierpipeline sind, voranzuschreiten, wodurch die Bandbreite des Befehlsdecodierers weiter erhöht wird.
  • Es wird jetzt auf 8 Bezug genommen, in der ein Taktzeitdiagramm für ein Beispiel eines Blasen-Zusammendrückens (bubble squeeze) veranschaulicht ist, welches von dem pipeline-verschachtelten Multi-Thread-Befehlsdecodierer gemäß der vorliegenden Erfindung ausgeführt werden kann. Die Signalverläufe 801, 802 und 803 in 8 sind jeweils zeitlich durch einen Taktzyklus getrennt. Der Signalverlauf 801 ist ein Taktdiagramm mit den Befehlszuständen, wie sie in den Pipelinestufen während der Zeit 1 angezeigt sind. Der Signalverlauf 802 ist ein Taktdiagramm mit den Befehlszuständen, wie sie in den Pipelinestufen während der Zeit 2 angezeigt sind. Der Signalverlauf 803 ist ein Taktdiagramm mit den Zuständen, wie sie in den Pipelinestufen während der Zeit 3 angezeigt sind. Die Befehlszustände für die Befehle in den Pipelinestufen sind unmittelbar über jedem Zyklus der Signalverläufe veranschaulicht und sind ein Kennzeichen, das den Thread-ID und das Befehl-Gültig-Bit für jede Pipelinestufe, die in der Schatten-Pipeline enthalten sind, repräsentiert. Der Zustand X zeigt einen ungültigen Befehl in einer gegebenen Pipelinestufe an. Der Zustand T0 (Kennzeichen oder Token Null), bei dem der Befehl als ein T0-Befehl bezeichnet wird, kennzeichnet einen gültigen Befehl in der Pipelinestufe mit einem Befehls-Thread-ID von Null (Thread-ID=0; ID0). Der Zustand T1 (Kennzeichen Eins), bei dem der Befehl als T1-Befehl bezeichnet wird, kennzeichnet einen gültigen Befehl in der Pipelinestufe mit einem Befehls-Thread-ID von Eins (Thread-ID=1; ID1). Befehle, die jedem der Kennzeichen T0 oder T1 zugeordnet sind, weisen den repräsentativen Zustand auf. Ein oder mehrere Apostrophe können in Verbindung mit dem Befehlszustand verwendet werden, um das Alter eines Befehls oder das Alter einer Ungültig-Bedingung in einer gegebenen Pipelinestufe anzuzeigen.
  • In 8 weist der Signalverlauf 801 während der Zeit 1 eine Blase ungültiger Befehle mit dem Zustand X in den früheren Pipelinestufen PS2 und PS3 auf. Ein Befehl 410', ein dem Kennzeichen Eins (T1) zugeordneter T1-Befehl wird der Befehlsdecodierpipeline eingegeben. Es sei angenommen, daß ein T0-thread-spezifisches Anhalten aufgrund des Empfangs eines Anhalte-Signals mit einem Thread-ID von Null auftrat, und daß ferner ein Taktzyklus auftrat, wobei der Signalverlauf 802 erzeugt wurde. Beim Signalverlauf 802 wurden die Takte der Pipelinestufen PS4 und PS5 angehalten. Der Anhaltezustand in der Pipelinestufe PS4, der vorletzten Pipelinestufe, kann aus der "Anhalten für vorletzte Pipelinestufe"-Gleichung, die in 7 veranschaulicht ist, berechnet werden, wobei NLP gleich 4 für die PS4 ist. Die vorletzte Pipelinestufe wird verwendet anstelle der letzten Pipelinestufe, um bei dem bevorzugten Ausführungsbeispiel eine Zykluszeit der Berechnung zur Verfügung zu stellen, bevor ein Befehl aus dem Befehlsdecodierer versendet wird. Bei alternativen Ausführungsbeispielen könnte die vorletzte Pipelinestufe durch die letzte Pipelinestufe in der Gleichung für "Anhalten für vorletzte Pipelinestufe" ersetzt werden, wobei NLP für die PS5 gleich 5 ist. Aus 7 erhalten wir: Stall(NLP) = Gültiger Befehl in Pipe(NLP) UND (ThreadID(NLP) = ThreadID des Stall)
  • Da der T0-Befehl in der Pipelinestufe PS5 ein gültiger Befehl ist und den T0-thread-spezifischen Anhalten (stall) (ThreadID = 0 = ThreadID des Stall) zugeordnet ist, existiert ein Stall-Zustand in der Pipelinestufe PS4. Die Takte zur Pipelinestufe PS4 werden somit für den nächsten Taktzyklus AUS-geschaltet, um den Befehl zu halten. Dies kann aus der Gleichung für "Taktfreigabe für eine Pipelinestufe X", die in 7 veranschaulicht ist, bestimmt werden. Takt(X) = NICHT Stall(X) UND NICHT Herunterschalten(X)
  • Da ein Anhaltezustand in der Pipelinestufe PS4 vorhanden ist, ist ihr Taktfreigabesignal niedrig, um im nächsten Taktzyklus den Takt anzuhalten.
  • Der Anhaltezustand in der Pipelinestufe PS5 kann aus der "Anhalten für eine andere Pipelinestufe X"-Gleichung, die in 7 veranschaulicht ist, berechnet werden, wobei X für PS5 kann aus der "Anhalten für eine andere Pipelinestufe X"-Gleichung, die in 7 veranschaulicht ist, berechnet werden, wobei X für PS5 gleich 5 ist. Stall(X) = Gültiger Befehl in Pipe(X) UND gültiger Befehl in Pipe(X+1) UND Stall(NLP)
  • Da die Pipelinestufe PS5 einen gültigen T0-Befehl aufweist und der vorhergehende Zyklus vermutlich einen gültigen Befehl versandte und ein Stall(NLP)-Zustand existiert, hat die Pipelinestufe PS5 ebenso einen Anhaltezustand. Die Takte zur Pipelinestufe PS5 werden somit ebenfalls AUS-geschaltet für den nächsten Taktzyklus, um den T0-Befehl zu halten. Da ein Anhalt-Zustand in der Pipelinestufe PS5 vorhanden ist, ist ihr Taktfreigabesignal, das durch die Gleichung "Taktfreigabe für eine Pipelinestufe X" berechnet wird, niedrig, um den Takt für den nächsten Taktzyklus anzuhalten. Folglich bewegen sich die T0-Befehle in den Pipelinestufe PS4 und PS5 in der Befehlsdecodierpipeline nicht vorwärts, sondern werden in den Pipelinestufen gehalten, und kein UOP wird von dem UOP-Versender 517 abgefertigt. Jedoch können sich T1-Befehle, die von dem Kennzeichen T1 repräsentiert werden und einem anderen Thread zugeordnet sind, in der Befehlsdecodierpipeline vorwärtsbewegen. Die Takte zu den Pipelinestufe PS1, PS2 und PS3 werden nicht angehalten, und der T1-Befehl in der Pipelinestufe PS1 wird in der Befehlsdecodierpipeline zu der Pipelinestufe PS2 in dem Signalverlauf 802 während des Zeitpunkts 2 vorgerückt. Während des Zeitpunkts 2 ist kein Anhalt-Zustand für die Pipelinestufe PS2 bei dem Signalverlauf 802 vorhanden, da es einen ungültigen Befehl in der nachfolgenden Pipelinestufe PS3 gibt. Wie es durch den Signalverlauf 802 angezeigt ist, wurde der zuvor in der Pipelinestufe PS2 zu findende ungültige Befehl durch eine T1-Befehl überschrieben. Da die Befehlsdecodierpipeline immer noch einen ungültigen Befehl aufweist, der in ihrer Pipelinestufe PS3 angeordnet ist, kann ein weiterer T1-Befehl 410' aus der Pipelinestufe PS1 auf dem nächsten Taktzyklus vorgerückt werden. Nach einem weiteren Taktzyklus wird der Signalverlauf 803 erzeugt. Bei dem Signalverlauf 803 wird der zuvor in der Pipelinestufe PS2 vorhandene T1-Befehl in die nächste Pipelinestufe PS3 vorgerückt, während ein T1-Befehl aus der Pipelinestufe PS1 in die Pipelinestufe PS2 vorgerückt wird. So wird der zweite ungültige Befehl, der zuvor in der Pipelinestufe PS3 beim Signalverlauf 802 angeordnet war, aus der Befehlsdecodierpipeline herausgedrückt (squeezed out). Bei Signalverlauf 803 wird, da die Befehlsdecodierpipeline jetzt voll ist, die gesamte Befehlsdecodierpipeline angehalten (stalled), und es erfolgen keine weiteren Taktungen irgendwelcher Pipelinestufen, bis das T0-thread-spezifische Anhalten gelöscht wird, um ein Versenden der UOPs zu gestatten. Auf diese Weise kann eine Blase (bubble) ungültiger Befehle aus dem Befehlsdecodierer herausgedrückt werden.
  • Es wird jetzt auf 9 Bezug genommen, in der ein Taktzeitdiagramm eines Beispiels eines nicht-blockierenden Anhaltens oder effizienten Anhaltens veranschaulicht ist, welches von dem Befehlsdecodierer gemäß der vorliegenden Erfindung ausgeführt werden kann. Die Signalverläufe 901, 902 und 903 in 9 sind jeweils zeitlich durch einen Taktzyklus getrennt. Die Signalverläufe 901, 902 und 903 sind Taktdiagramme, die die Befehlszustände während der Zeiten 1, 2 bzw. 3 veranschaulichen, wie sie über den Signalverläufen in den Pipelinestufen angezeigt werden. Die Befehlszustände haben dieselben Bedeutungen, wie sie zuvor unter Bezugnahme auf 8 erörtert wurden.
  • In 9 enthalten die Pipelinestufen in der Befehlsdecodierpipeline T1-Befehle aus einem Thread, der ein Thread-ID von Eins aufweist, und T0-Befehle aus einem Thread, der einen Thread-ID von Null aufweist, wobei diese jeweils durch das Kennzeichen über den Signalverläufen 901 angezeigt sind. Beim Signalverlauf 901 trifft ein T1-Befehl 410' in der Pipelinestufe PS1 ein, und ein weiterer T1-Befehl wird in der Pipelinestufe PS2 in einer decodierten Form gespeichert. Beim Signalverlauf 901 werden T0-Befehle in den Pipelinestufen PS3, PS4 und PS5 gespeichert. Nach einem weiteren Taktzyklus wird der Signalverlauf 902 erzeugt. Jeder Befehl in der Pipelinestufe, der durch den Signalverlauf 901 veranschaulicht worden ist, wurde in der Befehlsdecodierpipeline vorgerückt. Der zuvor in der Pipelinestufe PS5 des Signalverlaufs 901 vorhandene T0-Befehl wird von der Pipelinestufe PS5 während des Zeitpunkts 2 verschickt. Beim Signalverlauf 902 trifft ein T1-Befehl 410' in der Pipelinestufe PS1 ein, und weitere T1-Befehle sind in den Pipelinestufen PS2 und PS3 in decodierter Form gespeichert. Beim Signalverlauf 902 werden T0-Befehle jetzt in den Pipelinestufen PS4 und PS5 gespeichert. Jetzt sei angenommen, daß ein T1-thread-spezifisches Haltesignal von der Steuerlogik 401 empfangen wird, wobei der nächste Taktzyklus den Signalverlauf 903 erzeugt. Beim Signalverlauf 903 wird ein T0-Befehl in der Pipelinestufe PS5 gespeichert, während ein anderer T0-Befehl verschickt wird. Beim Signalverlauf 903 belegen T1-Befehle jetzt die Pipelinestufen PS1, PS2, PS3 und PS4. Da die Befehle in den späteren Pipelinestufen der Befehlsdecodierpipeline T0-Befehle und keine T1-Befehle sind, kann die Pipeline fortgesetzt getaktet werden, bis ein dem T1-thread-spezifischen Anhalten zugeordneter T1-Befehl die vorletzte Pipelinestufe PS4 erreicht. Wenn ein T1-Befehl die vorletzte Pipelinestufe PS4 erreicht, sind die Bedingungen für ein Anhalten aus der Gleichung für das "Anhalten für vorletzte Pipelinestufe (NLP)" erfüllt. Der PS5 belegende T0-Befehl wird an den Spur-Cache verschickt. Auf diese Weise kann das Anhalten (stalls) intelligent von dem Befehlsdecodierer gehandhabt werden.
  • Thread-spezifisches Löschen
  • Befehle können aus einer Reihe von Gründen ein Löschen erfordern. Ein Löschen macht im wesentlichen Befehle ungültig, so daß sie unberücksichtigt bleiben und mit gültigen Befehlen überschrieben werden können. Lösch-Signale können ausgegeben werden, um vollständige Threads von Befehlen, die einem spezifischen Thread-ID zugeordnet sind, ungültig zu machen. Diese Art des Löschens wird als thread-spezifisches Löschen bezeichnet. Ein thread-spezifisches Löschen zum Ungültig-Machen von Befehlen kann durch eine Reihe von Funktionsblöcken in einem Mikroprozessor erzeugt werden, einschließlich einem Speicher-Subsystem (beispielsweise selbst-modifizierender Code), der Befehlsdecodierpipeline selbst (z.B.: Verzweigungsadreßberechner oder X86-Decodierfehler), der Retirement-Einheit 320 oder anderer Back-End-Funktionsblöcke des Mikroprozessors. Der thread-spezifische Lösch-Algorithmus gemäß der vorliegenden Erfindung löscht nur Befehle aus der Befehlsdecodierpipeline, für die dies erforderlich ist, wobei gültige Befehle für eine fortgesetzte Decodierung und Ausführung durch den Mikroprozessor darin verbleiben. Der thread-spezifische Lösch-Algorithmus gemäß der vorliegenden Erfindung verwendet die Befehl-Gültig-Bits 416 und die Befehls-Thread-Identifikationsinformationen 418 in der Schatten-Pipeline 402, um Lösch-Signale nur an diejenigen Pipelinestufen auszugeben, die einen Befehl des zugehörigen zu löschenden Threads enthalten. Diese Lösch-Operationen machen das zugehörige Gültig-Bit derjenigen Befehle ungültig, die dem Thread entsprechen, das ungültig gemacht wird, und die in den jeweiligen Pipelinestufen der Befehlsdecodierpipeline enthalten sind. Ein thread-spezifisches Löschen der Befehlsdecodierpipeline gestattet das Entfernen eines Threads von Befehlen, während andere Threads von Befehlen intakt bleiben. Die intakten Befehle haben die Fähigkeit, in der Befehlsdecodierpipeline gegenüber solchen vorgerückt zu werden, welche durch Ungültig-Machen beseitigt worden sind. Ein thread-spezifisches Löschen kann während eines Anhaltens (stall) ausgeführt werden, um den Stall-Zustand zu eliminieren, wenn der das Anhalten verursachende Befehl gelöscht wird. Bei einem zyklus-basierten Prozessor-Entwurf werden die Pipelinestufen der Befehlsdecodierpipeline analysiert, um zu bestimmen, ob sie angehalten sind oder nicht, um ein thread-spezifisches Löschen zum Beseitigen der Stall-Bedingung auszuführen. Das thread-spezifische Löschen beseitigt im wesentlichen einen Thread, der in den Weg eines anderen Threads in der Befehlsdecodierpipeline gelangt. Dies löst das als Deadlock-Zustand bezeichnete Problem, welches bei einer Multi-Thread-Maschine auftritt, bei der sich mehrere Threads die gleiche Hardware teilen. Ein Deadlock-Zustand tritt beispielsweise auf, wenn ein Befehl des Thread-ID 0 angehalten wird und auf einen Befehl des Thread-ID 1 wartet, um irgend etwas auszuführen, aber der Befehl des Thread-ID 0 einen Befehl des Thread-ID 1 am Benutzen einer Ressource, wie beispielsweise dem Spur-Cache, hindert (blockiert). Wenn unter diesen Umständen die gesamte Pipeline gelöscht würde, gibt es keine Sicherheit, daß nicht derselbe Zustand erneut auftreten würde. Das thread-spezifische Löschen, das nur diejenigen Pipelinestufen löscht, die erforderlich sind, ermöglicht mehrere Threads, die sich eine einzige Hardware-Ressource teilen. Zusätzlich gibt es ein Sämtliche-Threads-Lösch-Signal, welches sämtliche Threads beeinflußt, indem es im Endeffekt sämtliche gültigen Befehle aus der Pipeline entfernt.
  • Es wird jetzt auf 10 Bezug genommen, in der ein Taktzeitdiagramm eines Beispiels eines thread-spezifischen Löschens veranschaulicht ist, welches von dem Befehlsdecodierer gemäß der vorliegenden Erfindung ausgeführt werden kann. Die Signalverläufe 1001, 1002 und 1003 sind jeweils zeitlich durch einen Taktzyklus getrennt. Die Signalverläufe 1001, 1002 und 1003 sind Taktdiagramme, die die Befehlszustände der Pipelinestufen während der Zeitpunkte 1, 2 bzw. 3 veranschaulichen. Die Zustände der Pipelinestufen werden unmittelbar über jeden Zyklus des Signalverlaufs veranschaulicht und haben dieselben Bedeutungen, wie die zuvor unter Bezugnahme auf 8 Erörterten.
  • In 10 weist der Signalverlauf 1001 T1-Befehle und T0-Befehle aus zwei Threads in seinen Pipelinestufen auf, wie es durch den Kennzeichen-Eins(T1)-Zustand und den Kennzeichen-Null(T0)-Zustand gekennzeichnet ist. Beim Signalverlauf 1001 sind die T0-Befehle in den Pipelinestufen PS2 und PS4. T1-Befehle sind in den Pipelinestufen PS3 und PS5 zum Zeitpunkt 1. Ein neuer Befehl 410', ein T1-Befehl, wird in die erste Pipelinestufe PS1 der Befehlsdecodierpipeline eingegeben. Beim Signalverlauf 1001 sind während der Zeit 1 sämtliche Befehle in den Pipelinestufen PS1-PS5 der Befehlsdecodierpipeline gültig. Jetzt sei angenommen, daß ein T1-thread-spezifisches Löschen empfangen worden ist. T1-Befehle, d.h. Befehle, welche dem durch das Kennzeichen (T1) dargestellten Thread zugeordnet sind, werden in den Pipelinestufen der Befehlsdecodierpipeline ungültig gemacht. Befehle werden ungültig gemacht, indem das Befehl-Gültig-Bit in den richtigen Pipelinestufen der Schatten-Pipeline gesetzt oder gelöscht werden. Bei dem Signalverlauf 1002 sind die Pipelinestufen sämtlich getaktet worden, um die Befehle in die nächste Pipelinestufe beim Voranschreiten aus dem Signalverlauf 1001 zu verschieben. Die Befehle in den Pipelinestufen in PS2 und PS4, welche anderenfalls T1-Befehle halten würden, sind jetzt in Ungültig-Zuständen, wie es durch das X angezeigt ist. Dies kann berechnet werden, indem die Gleichung "Löschen für eine Pipelinestufe X", welche in 7 veranschaulicht ist, analysiert wird. Löschen(X) = {Takt(X) UND [(LöscheThread(ID0) UND (ThreadID(X–1) = ID1)) ODER (LöscheThread(ID1) UND (ThreadID(X–1) = ID1))}ODER {NICHT Takt(X) UND [(LöscheThread(ID0) UND (ThreadID(X) = ID0)) ODER (LöscheThread(ID1) UND (ThreadID(X) = ID1))}
  • Diese Gleichung hat zwei Terme, einen Term mit Takt(X) und einen weiteren Term mit NICHT Takt(X). Im Ergebnis dessen, daß die Takte nicht angehalten werden, ist es in diesem Fall der Term mit Takt(X) von den beiden Termen, der ein Löschen bewirken könnte. Wenn eine Pipelinestufe angehalten würde, wäre es der Term mit NICHT Takt(X) der beiden Terme, der relevant wäre, zu bestimmen, daß eine Löschbedingung auftreten sollte. In dieser Gleichung ist LöscheThread(ID0) ein thread-spezifisches Löschen für einen Thread-ID von Null. LöscheThread(ID1) ist ein thread-spezifisches Löschen für einen Thread-ID von Eins. Die Pipelinestufe PS2 wird gelöscht, weil PS1 zum Zeitpunkt 1 bei der Signalform 1001 ein T1-Befehl ist, und weil ein T1-thread-spezifisches Löschen empfangen wurde, so daß bei dem nächsten Taktzyklus die Stufe PS2 gelöscht wird und ihr Befehl zu einem X ungültig gemacht wird. D.h., LöscheThread(ID1) war das T1-thread-spezifische Löschen und der Thread-ID von PS1 ist zum Zeitpunkt 1 gleich 1, so daß eine Löschbedingung vorhanden ist, die dazu führt, daß PS2 bei dem nächsten Taktzyklus gelöscht wird. Das Löschen der Pipelinestufe PS4 während des Zeitpunkts 2 kann auf ähnliche Weise unter Bezugnahme des zuvor in der Pipelinestufe PS3 während des Zeitpunkts 1 gehaltenen Werts erläutert werden.
  • Beim Signalverlauf 1002 erhalten die Pipelinestufen PS3 und PS5 T0-Befehle. Da ein T1-thread-spezifisches Löschen auftrat, wurde der Befehl in der Pipelinestufe PS5 während des Zeitpunkts 1, der ein T1-Befehl war, gelöscht, und somit wurde nichts von dem UOP-Abfertiger 517 während des Zeitpunkts 2 verschickt. Nach einem weiteren Taktzyklus wird der Signalverlauf 1003 erzeugt. Beim Signalverlauf 1003 wurden sämtliche Pipelinestufen getaktet, um die Befehle zur nächsten Pipelinestufe beim Voranschreiten aus dem Signalverlauf 1002 zu verschieben. Ein neuer Thread von Befehlen, die dem Kennzeichen Null (T0) zugeordnet sind, T0-Befehle, wird jetzt in die erste Pipelinestufe PS1 eingegeben. Die durch das X angezeigten ungültigen Befehle wurden in die Pipelinestufen PS3 und PS5 verschoben. T0-Befehle werden in den Pipelinestufen PS2 und PS4 gehalten, während ein T0-Befehl von dem UOP-Abfertiger 517 während der Zeit 3 verschickt wird. Auf diese Weise erfolgt ein thread-spezifisches Löschen der Pipelinestufen des Befehlsdecodierers. Sich auf andere Threads beziehende Befehle können in den Pipelinestufen verbleiben und ohne irgendeine Verzögerung weiter decodiert werden.
  • Opportunistisches Herunterschalten
  • Der opportunistische Herunterschalt-Algorithmus hält in einem Fall den Takt zu einer vollständigen Pipelinestufe der Schaltung (pro Pipe) an, um Energie einzusparen, anstelle nur eines Funktionsblocks. In einem anderen Fall kann der opportunistische Herunterschalt-Algorithmus den Takt zu irgendwelchen Pipelinestufen der Schaltung, die denselben Thread von Befehlen halten, (pro Thread) stoppen, wenn dieser Thread gelöscht wurde, um Energie einzusparen. In noch einem anderen Fall kann der opportunistische Herunterschalt-Algorithmus den Takt zu dem gesamten Befehlsdecodierer und irgendwelchen davor liegenden Schaltungen stoppen, wenn es keinen gültigen Befehl in dem Befehlsdecodierer oder in davor liegenden Schaltungen, die Befehle an den Befehlsdecodierer zur Verfügung stellen, gibt (pro Pipeline). Diese Bedingungen können durch eine Taktsteuerschaltung erfaßt werden, um zu bestimmen, wann das Taktfreigabesignal gesperrt werden soll, um den Takt zu einer oder zu mehreren Pipelinestufen der Schaltung AUSzuschalten. Da das Herunterschalten für einen Benutzer unsichtbar ist, gibt es keine Leistungs- oder Funktionsnachteile, der Algorithmus ist opportunistisch. Die Energieeinsparung ist die für einen Benutzer einzig bemerkbare Wirkung eines opportunistischen Herunterschalt-Algorithmus.
  • Der opportunistischen Herunterschalt-Algorithmus gemäß der vorliegenden Erfindung verwendet die Befehl-Gültig-Pipeline, um zu entscheiden, ob eine bestimmte Pipelinestufe getaktet werden soll oder nicht. Wenn ein gültiger Befehl, der unmittelbar vor einer Pipelinestufe steht, im Begriff ist, zu ihr vorzurücken, dann wird die den gültigen Befehl empfangende Pipelinestufe getaktet. Wenn kein gültiger Befehl wartet, der unmittelbar vorhergehende Befehl ungültig ist, werden die Takte zu der Pipelinestufe, die anderenfalls den ungültigen Befehl empfangen würde, AUS-geschaltet (d.h. die Takte gestoppt), um Energie einzusparen. In ähnlicher Weise können wir durch Überprüfen der Befehlsgültigkeitsinformationen in jeder Stufe der Schatten-Pipeline erfassen, wann eine jeweilige Stufe der gesamten Befehlspipeline verwendet wird, und der Taktsteuerlogik signalisieren, den Takt global für die Befehlsdecodierpipeline oder für Teile von dieser auszuschalten. Durch Stoppen der Takte auf diese Weise kann der Energieverbrauch des Befehlsdecodierers reduziert werden.
  • Es wird jetzt auf 11A und 11B Bezug genommen, in denen Taktzeitdiagramme von Beispielen opportunistischen Herunterschaltens veranschaulicht sind, welche von dem Befehlsdecodierer gemäß der vorliegenden Erfindung ausgeführt werden können. Diese Signalverläufe 1001, 1002 und 1003 sind Taktdiagramme, die dort, wo sie angezeigt sind, die Zustände der Pipelinestufen während der Zeiten 1, 2 bzw. 3, die jeweils durch einen Taktzyklus getrennt sind, veranschaulichen. Die Signalverläufe 1111, 1112, 1113, 1114 und 1115 sind Taktdiagramme, die die Zustände, wo sie angezeigt sind, der Pipelinestufen während der Zeiten 1, 2, 3, 4 bzw. 5 veranschaulichen, wobei diese jeweils durch einen Taktzyklus getrennt sind. Die Zustände der Pipelinestufen sind unmittelbar über jedem Zyklus der Signalverläufe veranschaulicht und haben dieselbe Bedeutungen, wie die zuvor unter Bezugnahme auf 8 Erörterten.
  • In 11A weist der Signalverlauf 1101 Befehle aus zwei Threads in seinen Pipelinestufen auf, wie es durch den Kennzeichen-1(T1)-Zustand und dem Kennzeichen-0(T0)-Zustand gekennzeichnet ist. Bei einem Signalverlauf 1101 sind T0-Befehle, d.h. Befehle eines Threads, der dem Kennzeichen 0 zugeordnet ist (T0), in den Pipelinestufen PS2 und PS4. T1-Befehle, Befehle eines dem Kennzeichen 1 (T1) zugeordneten Threads, sind in den Pipelinestufen PS3 und PS5. Ein neuer Befehl 410', ein T1-Befehl, wird der Pipelinestufe PS1 eingegeben. Da sämtliche Befehle in der Befehlsdecodierpipeline, wie sie durch den Signalverlauf 1101 während des Zeitpunkts 1 veranschaulicht ist, gültig sind, laufen sämtliche Takte zu jeder Pipelinestufe, um den nächsten Zyklus zu erzeugen. Jetzt sei angenommen, daß ein T1-thread-spezifisches Löschen empfangen worden ist, so daß T1-Befehle in denjenigen Pipelinestufen ungültig gemacht werden sollen, die diese Befehle auf dem nächsten Zyklus empfangen sollen.
  • Nachdem ein weiterer Taktzyklus auftrat, wird der Signalverlauf 1102 zum Zeitpunkt 2 gebildet. Beim Signalverlauf 1102 wurden sämtliche Pipelinestufen aus dem Signalverlauf 1101 so getaktet, daß die Befehle in die nächste Pipelinestufe im Voranschreiten verschoben werden. Wegen des T1- thread-spezifischen Löschens halten jetzt die Pipelinestufen PS2 und PS4, welche anderenfalls T1-Befehle halten würden, ungültige Befehle, wie es durch die Ungültig-Zustände X gekennzeichnet ist. Da ein T1-thread-spezifisches Löschen auftrat, wurde der letzte Befehl in der in Signalverlauf 1101 angezeigten Pipeline, der ein T1-Befehl ist, gelöscht, und somit wurde nichts von dem UOP-Abfertiger 517 während des Zeitpunkts 2 verschickt.
  • Damit der opportunistische Herunterschalt-Algorithmus in dem Befehlsdecodierer funktioniert, müssen eine oder mehrere Pipelinestufen ungültige Befehle enthalten. Eine gegebene Pipelinestufe [Pipe(X)] kann heruntergeschaltet werden, wenn der Befehl in der unmittelbar vorhergehenden Pipelinestufe [Pipe(X–1)] einen ungültigen Befehl enthält. Dies ist aus der Gleichung zum Herunterschalten für irgendeine Pipelinestufe X, die in 7 veranschaulicht ist, klar. Herunterschalten(X) = NICHT gültiger Befehl in Pipe(X–1)
  • Eine gegebene Pipelinestufe wird durch Ausschalten ihrer Takte AUS-geschaltet. Bei einem ungültigen Befehl hinter der gegebenen Pipelinestufe würde ein Takten der Pipelinestufe auf dem nächsten Zyklus zum Empfangen der ungültigen Daten, unnötig Energie verbrauchen. Beim Signalverlauf 1102 werden bei den Pipelinestufe PS3 und PS5 deren Takte für den nächsten Zyklus gestoppt, da die Pipelinestufen PS2 bzw. PS4 ungültige Befehle aufweisen, wie es durch X angezeigt ist. Jedoch wird bei Pipelinestufe [Pipe(X+1)], die einer Pipelinestufe mit gestopptem Takt unmittelbar vorhergeht, der Takt EIN-geschaltet, wenn keine Anhalt-Bedingung existiert, um den gültigen Befehl vorzurücken. Beim Signalverlauf 1102 wird bei der Pipelinestufe PS4 der Takt für den nächsten Zyklus laufengelassen, und der Puffer 502B empfängt eine Versende-Ausgabe auf dem nächsten Taktzyklus. Dies kann man aus der Gleichung für Taktfreigabe für eine Pipelinestufe X, die in 7 veranschaulicht ist, ersehen. Takt(X) = NICHT Stall(X) UND NICHT Herunterschalten(X)
  • Pipelinestufen mit ungültigen Befehlen, die der gegebenen Pipelinestufe mit dem gültigen Befehl vorangehen, werden kontinuierlich getaktet, bis ein gültiger Befehl darin enthalten ist.
  • Beim Signalverlauf 1102 läuft der Takt zu den Pipelinestufen PS2 und PS4 auf dem nächsten Taktzyklus, da es einen ungültigen Befehl in diesen Pipelinestufen gibt, was durch den X-Status gekennzeichnet ist. Auf diese Weise fährt der Befehlsdecodierer damit fort, zu decodieren, bis gültige Befehle in diesen Pipelinestufen decodiert werden. Der Takt zu den Pipelinestufen PS3 und PS5 wird gestoppt, da sie gültige Befehle halten, wie es durch das Kennzeichen T0 angezeigt ist.
  • Nachdem ein weiterer Taktzyklus auftrat, wird der Signalverlauf 1103 zum Zeitpunkt 3 gebildet. Beim Signalverlauf 1103 läuft der Takt zu den Pipelinestufen PS3 und PS5, um den nächsten Zyklus zu erzeugen, weil es einen alten Befehl in diesen Pipelinestufen gibt, wie es durch den T0'-Status angezeigt ist, weil der T0-Befehl zur nächsten Stufe voranschritt. Ein alter Befehl ist durch ein oder mehrere Apostroph-Symbole gekennzeichnet, was davon abhängt, wie viele Zyklen er in derselben Pipelinestufe verblieb. Ein alter Befehl ist ähnlich einem ungültigen Befehl insoweit, daß er überschrieben oder verworfen werden kann. Dies unterscheidet sich von einem angehaltenen Befehl, welcher noch gültig ist und nicht überschrieben werden kann. Auf diese Weise fährt der Befehlsdecodierer damit fort, zu decodieren, bis gültige Befehle in der Pipeline decodiert sind. Aus dem Signalverlauf 1103 wurde der Takt zu den Pipelinestufen PS2 und PS3 für den nächsten Zyklus angehalten, da sie gültige Befehle halten, wie es durch das Kennzeichen T0 angezeigt ist. Weil die Pipelinestufe PS5 einen gültigen T0-Befehl in dem vorhergehenden Taktzyklus hielt, wie es durch den Signalverlauf 1102 gekennzeichnet ist, wird der T0-Befehl durch den UOP-Versender 517 verschickt. Der Eingabebefehl 410', der in die Befehlsdecodierpipeline in die Pipelinestufe PS1 eingegeben wird, ist ungültig, wie es durch das X im Signalverlauf gekennzeichnet ist. Folglich wird der Takt zu der ersten Pipelinestufe PS1 gestoppt, um ein Lesen des ungültigen Befehls beim nächsten Taktzyklus zu vermeiden.
  • Es wird jetzt auf 11B Bezug genommen, in der ein Taktzeitdiagramm des zweiten Beispiels eines opportunistischen Herunterschaltens veranschaulicht ist. Der Signalverlauf 1111 weist Befehle aus zwei Threads in seinen Pipelinestufen auf, wie es durch den Kennzeichen-1(T1)-Zustand und den Kennzeichen-0(T0)-Zustand gekennzeichnet ist. Beim Signalverlauf 1111 ist ein T0-Befehl, ein Befehl eines dem Kennzeichen 0 (T0) zugeordneten Threads, in der Pipelinestufe PS4. T1-Befehle, d.h. Befehle eines dem Kennzeichen 1 (T1) zugeordneten Threads, sind in den Pipelinestufen PS2, PS3 und PS5. Ein neuer Befehl 410', ein T1-Befehl, wird der Pipelinestufe PS1 eingegeben. Da sämtliche Befehle in der Befehlsdecodierpipeline, die durch den Signalverlauf 1111 während des Zeitpunkts 1 veranschaulicht ist, gültig sind, laufen sämtliche Takte zu jeder Pipelinestufe, um den nächsten Zyklus zu erzeugen. Jetzt sei angenommen, daß ein T1-thread-spezifisches Löschen empfangen worden ist, so daß die T1-Befehle in den Pipelinestufen, die diese Befehle bei dem nächsten Zyklus empfangen sollen, ungültig zu machen sind.
  • Nachdem ein weiterer Taktzyklus auftrat, wird der Signalverlauf 1112 zum Zeitpunkt 2 gebildet. Im Signalverlauf 1112 sind sämtliche Pipelinestufen aus Signalverlauf 1111 getaktet worden, um die Befehle zu der nächsten Pipelinestufe beim Voranschreiten zu schieben. Aufgrund des T1-thread-spezifischen Löschens halten die Pipelinestufen PS2, PS3 und PS4, welche anderenfalls T1-Befehle halten würden, jetzt ungültige Befehle, wie es durch die ungültigen Zustände X gekennzeichnet ist. Da ein T1-thread-spezifisches Löschen auftrat, wurde der letzte Befehl in der im Signalverlauf 1111 gekennzeichneten Pipelinestufe, der ein T1-Befehl ist, gelöscht, und somit wurde nichts von dem UOP-Abfertiger 517 während der Zeit 2 verschickt. Beim Signalverlauf 1112 sind die Takte zu den Pipelinestufen PS3, PS4 und PS5 für den nächsten Zyklus angehalten, da die Pipelinestufen PS2, PS3 und PS4 jeweils ungültige Befehle aufweisen, wie es durch den X-Status gekennzeichnet ist. Die Pipelinestufe PS2 hat einen laufenden Takt, um den gültigen T0-Befehl zu empfangen, der in die erste Pipelinestufe PS1 im Signalverlauf 1112 eingegeben wird. Da der T0-Befehl in der Pipelinestufe PS5 gültig ist, empfängt der Puffer 502B eine Versende-Ausgabe beim nächsten Zyklus.
  • Nachdem ein weiterer Taktzyklus auftrat, wird zum Zeitpunkt 3 der Signalverlauf 1113 gebildet. Beim Signalverlauf 1113 läuft der Takt zur Pipelinestufe PS3, um den nächsten Zyklus zu erzeugen, da es einen alten ungültig gemachten Befehl in der Pipelinestufe PS3 gibt, wie es durch den X'-Status gekennzeichnet ist, um den T0-Befehl in der Pipelinestufe PS2 zu veranlassen, zu der nächsten Stufe voranzuschreiten. Beim Signalverlauf 1113 läuft der Takt zur Pipelinestufe PS2, um den nächsten Taktzyklus zu erzeugen, um den neuen T0-Befehl zu empfangen, welcher gegenwärtig in die erste Pipelinestufe PS1 aus der Befehlseingabe 410' eingegeben wird. Die Takte zu den Pipelinestufen PS4 und PS5 bleiben gestoppt wegen der nicht gültigen Befehle, die ihnen vorangehen. Die Befehle in den Pipelinestufen PS4 und PS5 altern um einen weiteren Zyklus zu X' bzw. T0'.
  • Nachdem ein weiterer Taktzyklus auftrat, wird zum Zeitpunkt 4 der Signalverlauf 1114 gebildet. Beim Signalverlauf 1114 läuft der Takt zur Pipelinestufe PS4, um den nächsten Zyklus zu erzeugen, da es einen alten ungültig gemachten Befehl in der Pipelinestufe PS4 gibt, wie es durch den X''-Status gekennzeichnet ist, um den T0-Befehl in der Pipelinestufe PS3 zu veranlassen, zur nächsten Stufe voranzuschrei ten. Beim Signalverlauf 1114 läuft der Takt zu den Pipelinestufen PS2 und PS3, um den nächsten Zyklus zu erzeugen, damit der neue T0-Befehl aus der vorhergehenden Pipelinestufe empfangen wird, nachdem er in die erste Pipelinestufe PS1 aus der Befehlseingabe 410' eingegeben worden ist. Der Takt zur Pipelinestufe PS5 bleibt gestoppt wegen des ungültigen Befehls, der ihr in der Pipelinestufe PS4 vorangeht. Der Befehl in der Pipelinestufe PS5 altert um einen weiteren Zyklus zu T0''.
  • Nachdem ein weiterer Taktzyklus auftrat, wird zum Zeitpunkt 5 der Signalverlauf 1115 gebildet. Beim Signalverlauf 1115 läuft der Takt zur Pipelinestufe PS5, um den nächsten Zyklus zu erzeugen, da es einen alten Befehl in der Pipelinestufe PS5 gibt, wie es durch T0''' angezeigt ist, um den T0-Befehl in der Pipelinestufe PS4 zu veranlassen, zur nächsten Stufe voranzuschreiten. Beim Signalverlauf 1115 läuft der Takt zu den Pipelinestufen PS2, PS3 und PS4 zum Erzeugen des nächsten Zyklus, um den neuen T0-Befehl aus der vorhergehenden Pipelinestufe zu empfangen, nachdem er in die erste Pipelinestufe PS1 aus der Befehlseingabe 410' eingegeben worden ist. Bei diesem Beispiel konnte der Takt zur Pipelinestufe PS5 in einem opportunistischen (angepaßten) Herunterschalten für drei Zyklen gestoppt werden. Der Takt zur Pipelinestufe PS4 konnte bei dem opportunistischen Herunterschalten für zwei Taktzyklen gestoppt werden. Der Takt zur Pipelinestufe PS3 konnte bei dem opportunistischen Herunterschalten für eine Taktzyklus gestoppt werden. In anderen Fällen eines opportunistischen Herunterschalt-Zustands wird mehr oder weniger Energie eingespart.
  • Die Algorithmen für ein effizientes Anhalten und Blasen-Zusammendrücken, thread-spezifisches Löschen und opportunistisches Herunterschalten stehen zueinander in Beziehung. Beispielsweise kann das Löschen eines speziellen Pipelinestufe unter Verwendung eines thread-spezifischen Löschens bewirken, daß ein Anhalten (stall) für eine gegebene Pipelinestufe beseitigt wird. Alternativ könnte ein thread-spezifisches Löschen Befehle in bestimmten Pipelinestufen ungültig machen, um einen opportunistischen Herunterschalt-Zustand zur Verfügung zu stellen.
  • Die vorliegende Erfindung hat viele Vorteile gegenüber dem Stand der Technik. Ein Vorteil der vorliegenden Erfindung besteht darin, daß Anhalt-Operationen im Front-End des Prozessors seltener auftreten. Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, daß "Blasen" ungültiger Befehle aus dem Befehlsfluß herausgedrückt werden können. Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, daß er Befehle in einem Thread in der Befehlsdecodierpipeline löschen kann, während andere Befehls-Threads intakt bleiben. Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, daß die Netto-Decodier-Bandbreite erhöht wird. Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, daß die Pipelinestufen in der Befehlsdecodierpipeline nur dann getaktet werden, wenn dies erforderlich ist, um einen gültigen Befehl voranzurücken, wodurch Energie eingespart wird. Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, daß sich mehrere Threads von Befehlen denselben Befehlsdecodierer teilen, um die Decodierleistung pro Thread bei geringen Implementierungskosten zu erhöhen.
  • Während bestimmte Ausführungsbeispiele beschrieben und in den beigefügten Zeichnungen gezeigt worden sind, ist es klar, daß diese Ausführungsbeispiele die breite Erfindung nur veranschaulichen und nicht einschränken sollen und daß diese Erfindung nicht auf die gezeigten und beschriebenen speziellen Konstruktionen und Anordnungen eingeschränkt ist, da verschiedene weitere Modifikationen Fachleuten in den Sinn kommen können. Beispielsweise ist die vorliegende Erfindung in ihrer Anwendung nicht nur auf Intel-X86-Befehlsdecodierungen eingeschränkt, sondern kann auf beliebige pipeline-verschachtelte Multi-Thread-Befehlsdecodierer angewendet werden. Darüber hinaus kann die vorliegende Erfindung an andere Funktionsbereiche und -blöcke eines Mikroprozessors, die ein Multi-Threading unterstützen, angepaßt werden, um die Hardware-Menge zum Unterstützen des Multi-Threading zu reduzieren, den Energieverbrauch zu reduzieren oder die negativen Einflüsse, die Anhalte-Operationen auf die Leistungsfähigkeit haben, zu reduzieren. Darüber hinaus ist es möglich, die vorliegende Erfindung oder einige ihrer Merkmale in Hardware, Firmware, Software oder einer Kombination dessen zu implementieren, wobei die Software in einem prozessor-lesbaren Speichermedium, wie beispielsweise einem magnetischen, optischen oder Haltleiterspeicher, zur Verfügung gestellt wird.

Claims (29)

  1. Mikroprozessor (201), aufweisend: einen Befehlsdecodierer (316) zum Decodieren mehrerer Threads eingegebener Befehle in Mikrooperanden, die von einer Ausführungseinheit (318) ausgeführt werden können, wobei der Befehlsdecodierer aufweist: eine Befehlsdecodierpipeline (400) zum Decodieren jedes eingegebenen Befehls in einen oder mehrere Mikrooperanden, wobei jeder eingegebene Befehl einem der mehreren Threads zugeordnet ist, und eine parallel zu der Befehlsdecodierpipeline (400) arbeitende Schatten-Pipeline (402), wobei die Schatten-Pipeline jedem Befehl, der gerade in der Befehlsdecodierpipeline decodiert wird, eine Thread-Identifikation und eine Gültig-Anzeige zuordnet, wobei die Thread-Identifikation und die Gültig-Anzeige verwendet werden, um auf der Ebene jeder Pipelinestufe Lösch-, Taktungs- und/oder Anhalte-Operationen zu steuern, wobei diejenigen Pipelinestufen, in denen ungültige Befehle enthalten sind, fortgesetzt getaktet werden, bis sie einen gültigen Befehl empfangen, wobei die gültigen Befehle jeweils die ungültigen Befehle überschreiben, womit die ungültigen Befehle aus der Pipeline herausgedrückt werden, und wobei der Takt zu einer einen gültigen Befehl enthaltenden Pipelinestufe vorübergehend gestoppt wird, bis der Grund für ein Anhalten (stalling) gelöscht ist ("Bubble Squeezing").
  2. Mikroprozessor nach Anspruch 1, dadurch gekennzeichnet, daß ein Befehl ungültig ist, wenn die zugeordnete Gültig-Anzeige gelöscht ist.
  3. Mikroprozessor nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der gültige Befehl in die nachfolgende Pipelinestufe auch dann hineingetaktet wird, wenn der in der nachfol genden Pipelinestufe vorhandene Befehl alt ist, d.h. in die nächste Pipelinestufe vorangeschritten ist.
  4. Mikroprozessor nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Schatten-Pipeline (402) aufweist: eine Befehls-Thread-Identifikations-Pipeline (602) die in jeder Pipelinestufe die Thread-Identifikation speichert, und eine Befehl-Gültig-Pipeline (601), die in jeder Pipelinestufe die Gültig-Anzeige speichert.
  5. Mikroprozessor nach Anspruch 1, dadurch gekennzeichnet, daß die Befehlsdecodierpipeline und die Schatten-Pipeline physisch in einer Pipeline in einer integrierten Schaltung eines Mikroprozessors integriert sind.
  6. Mikroprozessor nach Anspruch 4, dadurch gekennzeichnet, daß der Befehlsdecodierer (316) ferner eine Pipeline-Steuereinrichtung (401) aufweist, die mit der Befehlsdecodierpipeline (400) und der Schatten-Pipeline (402) gekoppelt ist, wobei die Pipeline-Steuereinrichtung dazu dient, parallel die Taktung jeder Pipelinestufe der Befehlsdecodierpipeline und jeder Pipelinestufe der Schatten-Pipeline zu steuern.
  7. Mikroprozessor nach Anspruch 6, dadurch gekennzeichnet, daß dann, wenn ein thread-spezifischer Lösch-Befehl empfangen wird, die Pipeline-Steuereinrichtung nur diejenigen Befehle in jeder angehaltenen Pipelinestufe der Befehlsdecodierpipeline ungültig macht, denen eine Thread-Identifikation zugeordnet ist, die der Thread-Identifikation des thread-spezifischen Löschens entspricht.
  8. Mikroprozessor nach Anspruch 6 oder 7, dadurch gekennzeichnet, daß die Pipeline-Steuereinrichtung Befehle in jeder Pipelinestufe ungültig macht, indem sie die Gültig-Anzeige in den parallelen Pipelinestufen der Befehl-Gültig-Pipeline löscht.
  9. Mikroprozessor nach Anspruch 6, dadurch gekennzeichnet, daß dann, wenn ein thread-spezifischer Lösch-Befehl empfangen wird, die Pipeline-Steuereinrichtung nur diejenigen Befehle ungültig macht, die in eine jeweilige getaktete Pipelinestufe der Befehlsdecodierpipeline eingegeben worden sind, wenn eine Pipelinestufe vor der jeweiligen getakteten Pipelinestufe eine Thread-Identifikation aufweist, die der Thread-Identifikation des thread-spezifischen Löschens entspricht.
  10. Mikroprozessor nach Anspruch 9, dadurch gekennzeichnet, daß die Pipeline-Steuereinrichtung Befehle in jeder Pipelinestufe ungültig macht, indem sie die Gültig-Anzeige in der parallelen Pipelinestufe der Befehl-Gültig-Pipeline löscht.
  11. Mikroprozessor nach Anspruch 6, dadurch gekennzeichnet, daß dann, wenn ein einer Thread-Identifikation zugeordnetes Anhalten (Stall) empfangen wird, die Pipeline-Steuereinrichtung bestimmt, ob die dem Anhalten zugeordnete Thread-Identifikation mit der Thread-Identifikation des gültigen Befehls in der vorletzten Pipelinestufe der Befehlsdecodierpipeline übereinstimmt, und die Pipeline-Steuereinrichtung die vorletzte Pipelinestufe anhält, indem sie den Takt zu der vorletzten Pipelinestufe für den nächsten Zyklus stoppt, um den darin enthaltenen gültigen Befehl zu halten.
  12. Mikroprozessor nach Anspruch 11, dadurch gekennzeichnet, daß die Pipeline-Steuereinrichtung ferner feststellt, daß ein gültiger Befehl in der ersten Pipelinestufe der Befehlsdecodierpipeline, die nicht die vorletzte Pipelinestufe ist, enthalten ist und ein gültiger Befehl in einer zweiten Pipelinestufe, die der ersten Pipelinestufe unmittelbar nachfolgt, enthalten ist, und die Pipeline-Steuereinrichtung die erste Pipelinestufe anhält, indem sie den Takt zu der ersten Pipe linestufe für den nächsten Zyklus stoppt, um den darin enthaltenen gültigen Befehl zu halten.
  13. Mikroprozessor nach Anspruch 12, dadurch gekennzeichnet, daß die Pipeline-Steuereinrichtung bestimmt, ob ein Befehl gültig ist, indem sie die Gültig-Anzeige in der Befehl-Gültig-Pipeline der jeweiligen Pipelinestufe analysiert.
  14. Mikroprozessor nach Anspruch 6, dadurch gekennzeichnet, daß die Pipeline-Steuereinrichtung ferner bestimmt, daß ein ungültiger Befehl in der ersten Pipelinestufe unmittelbar vor einer zweiten Pipelinestufe in der Befehlsdecodierpipeline enthalten ist, und die Pipeline-Steuereinrichtung die zweite Pipelinestufe herunterschaltet, indem sie den Takt zu der zweiten Pipelinestufe stoppt, bis ein gültiger Befehl der ersten Pipelinestufe enthalten ist, um Energie einzusparen.
  15. Mikroprozessor nach Anspruch 6, dadurch gekennzeichnet, daß die Pipeline-Steuereinrichtung (401) eine Herunterschalt-Logik (603) enthält, die die Gültig-Anzeige jeder Pipelinestufe analysiert, um zu bestimmen, ob die nächste Pipelinestufe heruntergeschaltet werden kann, und um zu bestimmen, ob eine jeweilige Pipelinestufe angehalten werden sollte, wobei die Pipeline-Steuereinrichtung (401) ferner eine Taktsteuer-Logik (604) enthält, um zu bestimmen, ob ein Taktsignal zu jeder Pipelinestufe der Befehlsdecodierpipeline und der Schatten-Pipeline gestoppt werden kann, um Energie einzusparen oder Daten während eines Anhaltens zu bewahren.
  16. Mikroprozessor nach Anspruch 15, dadurch gekennzeichnet, daß die Herunterschalt-Logik (603) der Pipeline-Steuereinrichtung zum Analysieren der Gültig-Anzeige jeder Pipelinestufe zum Bestimmen, ob die nächste Pipelinestufe heruntergeschaltet werden kann, einen Invertierer für jede Pipelinestufe zum Invertieren der Gültig-Anzeige einschließt, um zu bestimmen, ob die nächste Pipelinestufe für einen nächsten Taktzyklus heruntergeschaltet werden kann.
  17. Mikroprozessor nach Anspruch 15, dadurch gekennzeichnet, daß die Herunterschalt-Logik (603) der Pipeline-Steuereinrichtung zum Analysieren der Gültig-Anzeige jeder Pipelinestufe zum Bestimmen, ob die Pipelinestufe angehalten werden sollte, für eine Bestimmung einer Anhalt-Bedingung für die vorletzte Pipelinestufe einschließt: ein XOR-Gatter zum Ausführen einer Exklusiv-ODER-Operation zwischen der Thread-Identifikation der vorletzten Pipelinestufe und der Thread-Identifikation des Anhaltens, um zu bestimmen, ob sie übereinstimmen, und ein erstes UND-Gatter zum Ausführen einer UND-Verknüpfung der Gültig-Anzeige der vorletzten Pipelinestufe mit dem Ausgangssignal des XOR-Gatters, um zu bestimmen, ob eine Pipelinestufe vor der vorletzten Pipelinestufe angehalten werden sollte.
  18. Mikroprozessor nach Anspruch 17, dadurch gekennzeichnet, daß die Herunterschalt-Logik der Pipeline-Steuereinrichtung zum Analysieren der Gültig-Anzeige jeder Pipelinestufe zum Bestimmen, ob die Pipelinestufe angehalten werden sollte, für eine Bestimmung einer Anhalt-Bedingung für irgendeine andere Pipelinestufe mit Ausnahme der vorletzten Pipelinestufe für jede Pipelinestufe einschließt: ein zweites UND-Gatter zum UND-Verknüpfen der Gültig-Anzeige der Pipelinestufe, für welchen die Feststellung getroffen wird, und der Gültig-Anzeige der nächsten Pipelinestufe, und ein drittes UND-Gatter zum UND-Verknüpfen des Ausgangssignals des zweiten UND-Gatters mit dem Ausgangssignal des ersten UND-Gatters, um zu bestimmen, ob eine gegebene Pipelinestufe, die nicht die vorletzte Pipelinestufe ist, angehalten werden sollte.
  19. Mikroprozessor nach Anspruch 1, dadurch gekennzeichnet, daß die Befehlsdecodierpipeline eine Reihe von Registern in einer integrierten Schaltung eines Mikroprozessors enthält.
  20. Verfahren zum Decodieren mehrerer Threads von einem Befehlsdecodierer eingegebenen Befehlen in Mikrooperanden, die von einer Ausführungseinheit ausgeführt werden können, umfassend: Eingeben eines Befehls eines ersten Threads von Befehlen, einer ersten Befehls-Thread-Identifikation und einer ersten Befehl-Gültig-Anzeige parallel in eine Befehlsdecodierer-Pipeline des Befehlsdecodierers; Decodieren des Befehls des erste Threads von Befehlen; Aufrechterhalten der parallelen Zuordnung zwischen dem Befehl des ersten Threads, der ersten Befehls-Thread-Identifikation und der ersten Befehl-Gültig-Anzeige während der Decodierung des Befehls des ersten Threads von Befehlen; Eingeben eines Befehls eines zweiten Threads von Befehlen, einer zweiten Befehls-Thread-Identifikation und einer zweiten Befehl-Gültig-Anzeige parallel in die Befehlsdecodierer-Pipeline; Decodieren des Befehls des zweiten Threads von Befehlen; und Aufrechterhalten der parallelen Zuordnung zwischen dem Befehl des zweiten Threads von Befehlen, der zweiten Befehls-Thread-Identifikation und der zweiten Befehl-Gültig-Anzeige während der Decodierung des Befehls des zweiten Threads von Befehlen, wobei die Thread-Identifikation und die Gültig-Anzeige verwendet werden, um auf der Ebene jeder Pipelinestufe Lösch-, Taktungs- und/oder Anhalte-Operationen zu steuern, wobei diejenigen Pipelinestufen, in denen ungültige Befehle enthalten sind, fortgesetzt getaktet werden, bis sie einen gültigen Befehl empfangen, wobei die gültigen Befehle jeweils die ungültigen Befehle überschreiben, womit die ungültigen Befehle aus der Pipeline herausgedrückt werden, und wobei der Takt zu einer einen gültigen Befehl enthaltenden Pipelinestufe vorübergehend gestoppt wird, bis der Grund für ein Anhalten (stalling) gelöscht ist ("Bubble Squeezing").
  21. Verfahren nach Anspruch 20, ferner umfassend: Ungültig-Machen nur derjenigen Befehle, die eine erste Befehls-Thread-Identifikation in der Pipeline aufweisen, wenn ein thread-spezifisches Löschen für den ersten Befehls-Thread empfangen wird.
  22. Verfahren nach Anspruch 21, wobei die Befehle ungültig gemacht werden, indem die erste Befehl-Gültig-Anzeige für jeden Befehl des ersten Threads von Befehlen in der Pipeline gelöscht wird.
  23. Verfahren nach Anspruch 20, ferner umfassend: Sperren eines Taktsignals zu einer vorletzten Pipelinestufe in der Pipeline, wenn die Befehl-Gültig-Anzeige des in der vorletzten Pipelinestufe enthaltenen Befehls einen gültigen Befehl anzeigt und eine Thread-Identifikation eines thread-spezifischen Anhaltens mit der Thread-Identifikation des in der vorletzten Pipelinestufe enthaltenen Befehls übereinstimmt .
  24. Verfahren nach Anspruch 20, ferner umfassend: Sperren eines Taktsignals zu einer Pipelinestufe, die nicht die vorletzte Pipelinestufe in der Pipeline ist, wenn die bewertete Befehl-Gültig-Anzeige des in der Pipelinestufe enthaltenen Befehls einen gültigen Befehl anzeigt und die Befehl-Gültig-Anzeige des Befehls einer nächsten Pipelinestufe einen gültigen Befehl anzeigt und die vorletzte Pipelinestufe angehalten ist.
  25. Verfahren nach Anspruch 20, ferner umfassend: Freigeben eines Taktsignals zu einer Pipelinestufe, wenn die Pipelinestufe nicht angehalten wird und die Pipelinestufe nicht heruntergeschaltet ist.
  26. Verfahren nach Anspruch 20, ferner umfassend: Sperren eines Taktsignals zu einer Pipelinestufe, wenn eine vorhergehende Pipelinestufe einen ungültigen Befehl enthält, wie es durch eine Gültig-Anzeige des Befehls angezeigt wird, um Energie einzusparen.
  27. Verfahren nach Anspruch 20, umfassend: Empfangen eines thread-spezifischen Lösch-Befehls, der einen Thread-ID der aus der Befehlsdecodier-Pipeline zu löschenden Befehle anzeigt; Vergleichen eines Thread-Identifizierers jedes Befehls in jeder Pipelinestufe der Pipeline, um festzustellen, ob er mit dem Thread-ID der aus der Pipeline zu löschenden Befehle übereinstimmt; Ungültig-Machen eines Gültig-Bits für jeden Befehl, das einen mit dem Thread-ID der aus der Pipeline zu löschenden Befehle übereinstimmenden Thread-ID aufweist.
  28. Verfahren nach Anspruch 27, ferner umfassend Takten jeder Pipelinestufe der Pipeline, um das Decodieren der gültigen Befehle in der Pipeline, wie sie durch ihre Gültig-Bits gekennzeichnet sind, fortzusetzen.
  29. Computer, aufweisend: einen Speicher (204); und einen Mikroprozessor (201) nach einem der Ansprüche 1 bis 19.
DE10085375T 1999-12-30 2000-11-06 Verfahren und Einrichtung für einen pipeline-verschachtelten Multi-Thread-Befehlsdecodierer Expired - Fee Related DE10085375B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/475,105 1999-12-30
US09/475,105 US6609193B1 (en) 1999-12-30 1999-12-30 Method and apparatus for multi-thread pipelined instruction decoder
PCT/US2000/041927 WO2001050249A2 (en) 1999-12-30 2000-11-06 Method and apparatus for multi-thread pipelined instruction decoder

Publications (2)

Publication Number Publication Date
DE10085375T1 DE10085375T1 (de) 2002-12-05
DE10085375B4 true DE10085375B4 (de) 2007-01-25

Family

ID=23886242

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10085375T Expired - Fee Related DE10085375B4 (de) 1999-12-30 2000-11-06 Verfahren und Einrichtung für einen pipeline-verschachtelten Multi-Thread-Befehlsdecodierer

Country Status (8)

Country Link
US (2) US6609193B1 (de)
CN (2) CN1222868C (de)
AU (1) AU4302801A (de)
DE (1) DE10085375B4 (de)
GB (1) GB2374177B (de)
HK (1) HK1046970B (de)
TW (1) TW497072B (de)
WO (1) WO2001050249A2 (de)

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2728559B1 (fr) * 1994-12-23 1997-01-31 Saint Gobain Vitrage Substrats en verre revetus d'un empilement de couches minces a proprietes de reflexion dans l'infrarouge et/ou dans le domaine du rayonnement solaire
US6845445B2 (en) * 2000-05-12 2005-01-18 Pts Corporation Methods and apparatus for power control in a scalable array of processor elements
US6754808B1 (en) * 2000-09-29 2004-06-22 Intel Corporation Valid bit generation and tracking in a pipelined processor
JP3607209B2 (ja) * 2001-03-08 2005-01-05 松下電器産業株式会社 クロック制御方法及び当該クロック制御方法を用いた情報処理装置
WO2002077799A1 (en) * 2001-03-22 2002-10-03 Infineon Technologies Ag Program-controlled unit employing a stop instruction
US20030120896A1 (en) * 2001-06-29 2003-06-26 Jason Gosior System on chip architecture
JP3564445B2 (ja) * 2001-09-20 2004-09-08 松下電器産業株式会社 プロセッサ、コンパイル装置及びコンパイル方法
US20040025012A1 (en) * 2002-07-30 2004-02-05 Burks David Patrick System for processing coded content and associated decoding instructions on a removable storage medium
US20060149927A1 (en) * 2002-11-26 2006-07-06 Eran Dagan Processor capable of multi-threaded execution of a plurality of instruction-sets
US7496921B2 (en) * 2003-08-29 2009-02-24 Intel Corporation Processing block with integrated light weight multi-threading support
US7263599B2 (en) * 2004-02-06 2007-08-28 Infineon Technologies Thread ID in a multithreaded processor
US7418582B1 (en) 2004-05-13 2008-08-26 Sun Microsystems, Inc. Versatile register file design for a multi-threaded processor utilizing different modes and register windows
US7366829B1 (en) 2004-06-30 2008-04-29 Sun Microsystems, Inc. TLB tag parity checking without CAM read
US7543132B1 (en) 2004-06-30 2009-06-02 Sun Microsystems, Inc. Optimizing hardware TLB reload performance in a highly-threaded processor with multiple page sizes
US7290116B1 (en) 2004-06-30 2007-10-30 Sun Microsystems, Inc. Level 2 cache index hashing to avoid hot spots
US7571284B1 (en) 2004-06-30 2009-08-04 Sun Microsystems, Inc. Out-of-order memory transactions in a fine-grain multithreaded/multi-core processor
US7519796B1 (en) 2004-06-30 2009-04-14 Sun Microsystems, Inc. Efficient utilization of a store buffer using counters
US7509484B1 (en) 2004-06-30 2009-03-24 Sun Microsystems, Inc. Handling cache misses by selectively flushing the pipeline
US20060009265A1 (en) * 2004-06-30 2006-01-12 Clapper Edward O Communication blackout feature
US7523330B2 (en) * 2004-06-30 2009-04-21 Sun Microsystems, Inc. Thread-based clock enabling in a multi-threaded processor
US7890735B2 (en) * 2004-08-30 2011-02-15 Texas Instruments Incorporated Multi-threading processors, integrated circuit devices, systems, and processes of operation and manufacture
US8756605B2 (en) * 2004-12-17 2014-06-17 Oracle America, Inc. Method and apparatus for scheduling multiple threads for execution in a shared microprocessor pipeline
US7430643B2 (en) * 2004-12-30 2008-09-30 Sun Microsystems, Inc. Multiple contexts for efficient use of translation lookaside buffer
WO2006075286A2 (en) 2005-01-13 2006-07-20 Nxp B.V. A processor and its instruction issue method
EP1859346B1 (de) * 2005-03-04 2012-01-11 Hewlett-Packard Development Company, L.P. Verfahren und vorrichtung zum erleichtern des pipeline-durchsatzes
US20060212853A1 (en) * 2005-03-18 2006-09-21 Marvell World Trade Ltd. Real-time control apparatus having a multi-thread processor
US8195922B2 (en) 2005-03-18 2012-06-05 Marvell World Trade, Ltd. System for dynamically allocating processing time to multiple threads
US7949854B1 (en) 2005-09-28 2011-05-24 Oracle America, Inc. Trace unit with a trace builder
US7606975B1 (en) 2005-09-28 2009-10-20 Sun Microsystems, Inc. Trace cache for efficient self-modifying code processing
US8019944B1 (en) 2005-09-28 2011-09-13 Oracle America, Inc. Checking for a memory ordering violation after a speculative cache write
US7870369B1 (en) 2005-09-28 2011-01-11 Oracle America, Inc. Abort prioritization in a trace-based processor
US8015359B1 (en) 2005-09-28 2011-09-06 Oracle America, Inc. Method and system for utilizing a common structure for trace verification and maintaining coherency in an instruction processing circuit
US7849292B1 (en) 2005-09-28 2010-12-07 Oracle America, Inc. Flag optimization of a trace
US8499293B1 (en) 2005-09-28 2013-07-30 Oracle America, Inc. Symbolic renaming optimization of a trace
US7814298B1 (en) 2005-09-28 2010-10-12 Oracle America, Inc. Promoting and appending traces in an instruction processing circuit based upon a bias value
US7877630B1 (en) 2005-09-28 2011-01-25 Oracle America, Inc. Trace based rollback of a speculatively updated cache
US7953933B1 (en) 2005-09-28 2011-05-31 Oracle America, Inc. Instruction cache, decoder circuit, basic block cache circuit and multi-block cache circuit
US8051247B1 (en) 2005-09-28 2011-11-01 Oracle America, Inc. Trace based deallocation of entries in a versioning cache circuit
US8037285B1 (en) 2005-09-28 2011-10-11 Oracle America, Inc. Trace unit
US8370576B1 (en) 2005-09-28 2013-02-05 Oracle America, Inc. Cache rollback acceleration via a bank based versioning cache ciruit
US7783863B1 (en) 2005-09-28 2010-08-24 Oracle America, Inc. Graceful degradation in a trace-based processor
US7937564B1 (en) 2005-09-28 2011-05-03 Oracle America, Inc. Emit vector optimization of a trace
US8024522B1 (en) 2005-09-28 2011-09-20 Oracle America, Inc. Memory ordering queue/versioning cache circuit
US7953961B1 (en) 2005-09-28 2011-05-31 Oracle America, Inc. Trace unit with an op path from a decoder (bypass mode) and from a basic-block builder
US7966479B1 (en) 2005-09-28 2011-06-21 Oracle America, Inc. Concurrent vs. low power branch prediction
US8032710B1 (en) 2005-09-28 2011-10-04 Oracle America, Inc. System and method for ensuring coherency in trace execution
US7987342B1 (en) 2005-09-28 2011-07-26 Oracle America, Inc. Trace unit with a decoder, a basic-block cache, a multi-block cache, and sequencer
US20070101102A1 (en) * 2005-10-27 2007-05-03 Dierks Herman D Jr Selectively pausing a software thread
US7797517B1 (en) 2005-11-18 2010-09-14 Oracle America, Inc. Trace optimization via fusing operations of a target architecture operation set
US7444499B2 (en) * 2006-03-28 2008-10-28 Sun Microsystems, Inc. Method and system for trace generation using memory index hashing
US8370609B1 (en) 2006-09-27 2013-02-05 Oracle America, Inc. Data cache rollbacks for failed speculative traces with memory operations
US8010745B1 (en) 2006-09-27 2011-08-30 Oracle America, Inc. Rolling back a speculative update of a non-modifiable cache line
US8402253B2 (en) 2006-09-29 2013-03-19 Intel Corporation Managing multiple threads in a single pipeline
US7975272B2 (en) * 2006-12-30 2011-07-05 Intel Corporation Thread queuing method and apparatus
WO2008155826A1 (ja) * 2007-06-19 2008-12-24 Fujitsu Limited キャッシュ制御装置およびキャッシュ制御方法
WO2008155840A1 (ja) * 2007-06-20 2008-12-24 Fujitsu Limited 命令制御装置及び命令制御方法
US20090044159A1 (en) * 2007-08-08 2009-02-12 Mplicity Ltd. False path handling
US9035957B1 (en) * 2007-08-15 2015-05-19 Nvidia Corporation Pipeline debug statistics system and method
US8868888B2 (en) * 2007-09-06 2014-10-21 Qualcomm Incorporated System and method of executing instructions in a multi-stage data processing pipeline
CN101425053B (zh) * 2007-11-02 2010-08-18 北京中电华大电子设计有限责任公司 一种cpu周期寄存器的实现方法
US8543796B2 (en) 2008-11-05 2013-09-24 Intel Corporation Optimizing performance of instructions based on sequence detection or information associated with the instructions
US9710277B2 (en) * 2010-09-24 2017-07-18 Intel Corporation Processor power management based on class and content of instructions
US9747107B2 (en) 2012-11-05 2017-08-29 Nvidia Corporation System and method for compiling or runtime executing a fork-join data parallel program with function calls on a single-instruction-multiple-thread processor
US9417880B2 (en) 2013-03-15 2016-08-16 Intel Corporation Instruction for performing an overload check
CN105263023B (zh) * 2015-10-26 2018-08-03 西安电子科技大学 基于高速解码平台的网络码流实时接收方法
CN105654383B (zh) * 2016-01-07 2019-12-10 中国科学院信息工程研究所 基于流水线架构的低时延fast行情解码装置和方法
US10325341B2 (en) 2017-04-21 2019-06-18 Intel Corporation Handling pipeline submissions across many compute units
US10269088B2 (en) * 2017-04-21 2019-04-23 Intel Corporation Dynamic thread execution arbitration
WO2020009989A1 (en) * 2018-07-05 2020-01-09 Mythic, Inc. Systems and methods for implementing an intelligence processing computing architecture
KR20200088701A (ko) * 2019-01-15 2020-07-23 에스케이하이닉스 주식회사 커맨드 생성 방법 및 이를 이용한 반도체장치

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5778246A (en) * 1995-12-27 1998-07-07 Intel Corporation Method and apparatus for efficient propagation of attribute bits in an instruction decode pipeline
US5890008A (en) * 1997-06-25 1999-03-30 Sun Microsystems, Inc. Method for dynamically reconfiguring a processor

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5539911A (en) 1991-07-08 1996-07-23 Seiko Epson Corporation High-performance, superscalar-based computer system with out-of-order instruction execution
US5357617A (en) * 1991-11-22 1994-10-18 International Business Machines Corporation Method and apparatus for substantially concurrent multiple instruction thread processing by a single pipeline processor
US5983339A (en) 1995-08-21 1999-11-09 International Business Machines Corporation Power down system and method for pipelined logic functions
US6026476A (en) 1996-03-19 2000-02-15 Intel Corporation Fast fully associative translation lookaside buffer
US5913049A (en) 1997-07-31 1999-06-15 Texas Instruments Incorporated Multi-stream complex instruction set microprocessor
US6385719B1 (en) * 1999-06-30 2002-05-07 International Business Machines Corporation Method and apparatus for synchronizing parallel pipelines in a superscalar microprocessor
US6357016B1 (en) * 1999-12-09 2002-03-12 Intel Corporation Method and apparatus for disabling a clock signal within a multithreaded processor
US6594755B1 (en) * 2000-01-04 2003-07-15 National Semiconductor Corporation System and method for interleaved execution of multiple independent threads
US6754808B1 (en) * 2000-09-29 2004-06-22 Intel Corporation Valid bit generation and tracking in a pipelined processor

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5778246A (en) * 1995-12-27 1998-07-07 Intel Corporation Method and apparatus for efficient propagation of attribute bits in an instruction decode pipeline
US5890008A (en) * 1997-06-25 1999-03-30 Sun Microsystems, Inc. Method for dynamically reconfiguring a processor

Also Published As

Publication number Publication date
AU4302801A (en) 2001-07-16
WO2001050249A2 (en) 2001-07-12
DE10085375T1 (de) 2002-12-05
US20040107336A1 (en) 2004-06-03
GB2374177B (en) 2004-07-07
CN100361073C (zh) 2008-01-09
CN1222868C (zh) 2005-10-12
US6609193B1 (en) 2003-08-19
WO2001050249A9 (en) 2002-08-01
WO2001050249A3 (en) 2002-05-02
TW497072B (en) 2002-08-01
CN1437725A (zh) 2003-08-20
HK1046970B (zh) 2004-12-31
GB2374177A (en) 2002-10-09
GB0214930D0 (en) 2002-08-07
HK1046970A1 (en) 2003-01-30
US6931516B2 (en) 2005-08-16
CN1725176A (zh) 2006-01-25

Similar Documents

Publication Publication Date Title
DE10085375B4 (de) Verfahren und Einrichtung für einen pipeline-verschachtelten Multi-Thread-Befehlsdecodierer
DE69534148T2 (de) Rechnersystem zur Ausführung von Verzweigungsbefehlen
DE19983589B4 (de) Hochfrequenz-Pipeline-Entkopplungswarteschlangengestaltung
DE60036016T2 (de) Schnell multithreading für eng gekoppelte multiprozessoren
DE112004002296B4 (de) Anwenderprogrammierbares Multithreading mit geringem Overhead
DE69929936T2 (de) Verfahren und Vorrichtung zum Abrufen von nicht-angrenzenden Befehlen in einem Datenverarbeitungssystem
DE10353268B3 (de) Paralleler Multithread-Prozessor (PMT) mit geteilten Kontexten
DE69727773T2 (de) Verbesserte Verzweigungsvorhersage in einem Pipelinemikroprozessor
DE4206062C2 (de) Pipelineverarbeitung von Instruktionen
DE10084556B4 (de) Optimierte Ausführung von statisch sehr wahrscheinlich vorhergesagten Verzweigungsbefehlen
DE69835100T2 (de) Prozessor konfiguriert um vorausschauende resultate von zusammengefassten übertragungs-, vergleichs- und einfachen arithmetischen befehlen zu produzieren
DE3914265C2 (de)
DE10085373B4 (de) Verfahren zum Flushen von Cache-Zeilen
DE4237417C2 (de) Datenverarbeitungssystem
DE69434669T2 (de) Spekulative Befehlswarteschlange für Befehle mit variabler Byteslänge
DE102009051388A1 (de) Technik zur Förderung effizienter Befehlsfusion
DE102014000382A1 (de) Vorhersage indirekter Abzweigungen
DE112004002365T5 (de) Übergang vom Befehls-Cache-Speicher zum Ablaufverfolgungs-Cache-Speicher basierend auf Markengrenzen
DE112004002267T5 (de) Ruhezustandsmechansimus für virtuelles Multithreading
DE112006003632B4 (de) Dynamische selbstzerfallende Bauteilarchitektur
DE69727177T2 (de) Emulation von asynchronen Signalen mit Verzweigungsmechanismus
DE10113191B4 (de) Spekulatives Vorausräumen von Daten in einem Prozessorsystem mit einer ungeordneten Ausführung
DE19824289C2 (de) Pipelineverarbeitungsmaschine
DE3700800C2 (de) Einrichtung zur Erzeugung eines Unterbrechungspunktes in einem Mikroprozessor
DE3740762A1 (de) Datenverarbeitungssystem mit einer externen schnittstelle

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20140603