Datei registrieren - Register file

Eine Registerdatei ist ein Array von Prozessorregistern in einer zentralen Verarbeitungseinheit (CPU). Registerbanking ist die Methode, mit einem einzigen Namen auf mehrere verschiedene physische Register je nach Betriebsmodus zuzugreifen. Moderne Registerdateien auf Basis von integrierten Schaltungen werden üblicherweise durch schnelle statische RAMs mit mehreren Ports implementiert . Solche RAMs zeichnen sich dadurch aus, dass sie dedizierte Lese- und Schreibports aufweisen, während gewöhnliche Multiport-SRAMs normalerweise über dieselben Ports lesen und schreiben.

Die Befehlssatzarchitektur einer CPU definiert fast immer einen Satz von Registern, die verwendet werden, um Daten zwischen dem Speicher und den Funktionseinheiten auf dem Chip bereitzustellen. In einfacheren CPUs entsprechen diese Architekturregister eins zu eins den Einträgen in einer physischen Registerdatei (PRF) innerhalb der CPU. Kompliziertere CPUs verwenden eine Registerumbenennung , so dass sich die Abbildung, welcher physische Eintrag ein bestimmtes Architekturregister speichert, während der Ausführung dynamisch ändert. Die Registerdatei ist Teil der Architektur und für den Programmierer sichtbar, im Gegensatz zum Konzept transparenter Caches .

Bankwechsel registrieren

Registerdateien können als Registerbanken zusammengefaßt werden. Ein Prozessor kann mehr als eine Registerbank haben.

ARM-Prozessoren verfügen über Register mit und ohne Bank. Während alle Modi die gleichen physikalischen Register für die ersten acht allgemeinen Register R0 bis R7 immer teilen, das physikalische Register , die die überhöhten Register R8 bis R14, um Punkt auf der Betriebsart hängt der Prozessor in ist. Bemerkenswert ist , schnelle Interrupt Der Anforderungsmodus (FIQ) hat seine eigene Registerbank für R8 bis R12, wobei die Architektur auch einen privaten Stapelzeiger (R13) für jeden Unterbrechungsmodus bereitstellt.

x86- Prozessoren verwenden Kontextumschaltung und schnelle Unterbrechung zum Umschalten zwischen Befehls-, Decoder-, GPRs- und Registerdateien, wenn mehr als eine vorhanden ist, bevor der Befehl ausgegeben wird, aber dies ist nur bei Prozessoren vorhanden, die Superskalar unterstützen. Die Kontextumschaltung ist jedoch ein völlig anderer Mechanismus als die Registerbank von ARM innerhalb der Register.

Der MODCOMP und die späteren 8051-kompatiblen Prozessoren verwenden Bits im Programmstatuswort, um die derzeit aktive Registerbank auszuwählen.

Implementierung

Regfile array.png

Die übliche Layoutkonvention ist, dass ein einfaches Array vertikal ausgelesen wird. Das heißt, eine einzelne Wortleitung, die horizontal verläuft, bewirkt, dass eine Reihe von Bitzellen ihre Daten auf Bitleitungen ablegt, die vertikal verlaufen. Leseverstärker , der Low-Swing konvertieren Bitleitungen in vollem Gang Logikpegel zu lesen, ist in der Regel am Boden (durch Konvention). Größere Registerdateien werden dann manchmal konstruiert, indem gespiegelte und gedrehte einfache Arrays gekachelt werden.

Registerdateien haben eine Wortleitung pro Eintrag pro Port, eine Bitleitung pro Bit Breite pro Leseport und zwei Bitleitungen pro Bit Breite pro Schreibport. Jede Bitzelle hat auch Vdd und Vss. Daher nimmt die Drahtabstandsfläche mit dem Quadrat der Anzahl von Ports zu, und die Transistorfläche nimmt linear zu. An einem bestimmten Punkt kann es kleiner und/oder schneller sein, mehrere redundante Registerdateien mit einer geringeren Anzahl von Leseports zu haben, anstatt eine einzelne Registerdatei mit allen Leseports. Die Integer- Einheit des MIPS R8000 beispielsweise hatte eine 64-Bit-Registerdatei mit 9 Lese- und 4 Schreibports mit 32 Einträgen , die in einem 0,7-µm-Prozess implementiert wurde, was bei Betrachtung des Chips aus Armlänge zu sehen war.

Zwei gängige Ansätze zum Aufteilen von Registern in mehrere Registerdateien sind die Konfiguration mit verteilten Registerdateien und die Konfiguration mit partitionierten Registerdateien.

Im Prinzip könnte jede Operation, die mit einer 64 Bit breiten Registerdatei mit vielen Lese- und Schreibports durchgeführt werden könnte, mit einer einzelnen 8 Bit breiten Registerdatei mit einem einzelnen Leseport und einem einzelnen Schreibport ausgeführt werden. Die Parallelität auf Bitebene von breiten Registerdateien mit vielen Ports ermöglicht es ihnen jedoch, viel schneller zu laufen, und somit können sie Operationen in einem einzigen Zyklus ausführen, die viele Zyklen mit weniger Ports oder einer schmaleren Bitbreite oder beidem benötigen würden.

Die Breite in Bit der Registerdatei ist normalerweise die Anzahl der Bits in der Wortgröße des Prozessors . Gelegentlich ist es etwas breiter, um jedem Register "zusätzliche" Bits hinzuzufügen, wie beispielsweise das Giftbit. Wenn die Breite des Datenworts von der Breite einer Adresse abweicht – oder in einigen Fällen, wie beim 68000 , selbst wenn sie dieselbe Breite haben – befinden sich die Adressregister in einer separaten Registerdatei als die Datenregister.

Decoder

  • Der Decoder wird oft in einen Vordecoder und einen eigentlichen Decoder unterteilt.
  • Der Decoder ist eine Reihe von UND-Gattern, die Wortleitungen ansteuern.
  • Es gibt einen Decoder pro Lese- oder Schreibport. Wenn das Array beispielsweise vier Lese- und zwei Schreibports hat, hat es 6 Wortleitungen pro Bitzelle im Array und sechs UND-Gatter pro Zeile im Decoder. Beachten Sie, dass der Decoder an das Array angepasst werden muss, was dazu führt, dass diese UND-Gatter breit und kurz sind

Array

Eine typische Registerdatei - "dreifach portiert", die gleichzeitig aus 2 Registern lesen und in 1 Register schreiben kann - besteht aus Bitzellen wie dieser.

Das Grundschema für eine Bitzelle:

  • Der Zustand wird im Wechselrichterpaar gespeichert.
  • Daten werden von einem nmos-Transistor auf eine Bitleitung ausgelesen.
  • Daten werden geschrieben, indem eine Seite oder die andere über einen Zwei-nmos-Stack mit Masse kurzgeschlossen wird.
  • Also: Leseports benötigen einen Transistor pro Bitzelle, Schreibports nehmen vier.

Viele Optimierungen sind möglich:

  • Teilen von Leitungen zwischen Zellen, zum Beispiel Vdd und Vss.
  • Lesebitleitungen werden oft auf einen Wert zwischen Vdd und Vss vorgeladen.
  • Lesebitleitungen schwingen oft nur einen Bruchteil des Weges zu Vdd oder Vss. Ein Leseverstärker wandelt dieses Kleinschwingungssignal in einen vollen Logikpegel um. Kleine Schwingsignale sind schneller, weil die Bitleitung wenig Ansteuerung, aber viel parasitäre Kapazität hat.
  • Schreibbitleitungen können geflochten sein, so dass sie gleichmäßig mit den nahegelegenen Lesebitleitungen koppeln. Da Schreibbitleitungen in vollem Gange sind, können sie erhebliche Störungen auf Lesebitleitungen verursachen.
  • Wenn Vdd eine horizontale Zeile ist, kann sie durch noch einen anderen Decoder ausgeschaltet werden, wenn einer der Schreibports diese Zeile während dieses Zyklus schreibt. Diese Optimierung erhöht die Schreibgeschwindigkeit.
  • Techniken, die den Energieverbrauch von Registerdateien reduzieren, sind in der Low-Power-Elektronik nützlich

Mikroarchitektur

Die meisten Registerdateien treffen keine besonderen Vorkehrungen, um zu verhindern, dass mehrere Schreibports gleichzeitig denselben Eintrag schreiben. Stattdessen stellt die Befehlsplanungshardware sicher, dass nur ein Befehl in einem bestimmten Zyklus einen bestimmten Eintrag schreibt. Wenn mehrere Befehle ausgegeben werden, die auf dasselbe Register abzielen, werden alle bis auf einen Schreibfreigaben ausgeschaltet.

Die gekreuzten Inverter brauchen eine endliche Zeit, um sich nach einer Schreiboperation einzuschwingen, während eine Leseoperation entweder länger dauert oder Müll zurückgibt. Es ist üblich, Bypass-Multiplexer zu haben, die geschriebene Daten an die Leseports umgehen, wenn ein gleichzeitiges Lesen und Schreiben in denselben Eintrag befohlen wird. Diese Bypass-Multiplexer sind oft Teil eines größeren Bypass-Netzwerks, das Ergebnisse, die noch nicht festgeschrieben wurden, zwischen Funktionseinheiten weiterleitet.

Die Registerdatei wird normalerweise an den Datenpfad angepasst, den sie bedient. Die Tonhöhenanpassung vermeidet, dass viele Busse über den Datenpfad abbiegen, was viel Fläche beanspruchen würde. Aber da jede Einheit den gleichen Bitabstand haben muss, endet jede Einheit im Datenpfad mit dem Bitabstand, der von der breitesten Einheit erzwungen wird, was in den anderen Einheiten Platz verschwenden kann. Registerdateien können oft die Schrittweite eines Datenpfads einstellen, da sie zwei Drähte pro Bit pro Schreibport haben und weil alle Bitleitungen das Silizium an jeder Bitzelle kontaktieren müssen.

Auf Maschinen mit mehreren Einheiten in einem Datenpfad kann manchmal Bereich gespart werden, indem zwei Datenpfade nebeneinander vorhanden sind, von denen jeder einen kleineren Bitabstand hat als ein einzelner Datenpfad. Dieser Fall erzwingt normalerweise mehrere Kopien einer Registerdatei, eine für jeden Datenpfad.

Die Alpha 21264 (EV6) beispielsweise war die erste große Mikroarchitektur , die die "Shadow Register File Architecture" implementierte. Es hatte zwei Kopien der Ganzzahlregisterdatei und zwei Kopien des Gleitkommaregisters, die sich in seinem Front-End befinden (zukünftige und skalierte Datei, die jeweils 2 Lese- und 2 Schreibports enthalten) und brauchten einen zusätzlichen Zyklus, um Daten zwischen den beiden zu verbreiten Kontextwechsel. Die Problemlogik versuchte, die Anzahl der Operationen zur Weiterleitung von Daten zwischen den beiden zu reduzieren, und verbesserte ihre ganzzahlige Leistung erheblich und trug dazu bei, die Auswirkungen einer begrenzten Anzahl von GPR bei der superskalaren und spekulativen Ausführung zu reduzieren. Das Design wurde später von SPARC , MIPS und einigen späteren x86-Implementierungen angepasst .

Das MIPS verwendet auch mehrere Registerdateien; die Gleitkommaeinheit R8000 hatte zwei Kopien der Gleitkommaregisterdatei mit jeweils vier Schreib- und vier Leseports und schrieb beide Kopien gleichzeitig mit Kontextwechsel. Es unterstützte jedoch keine Integer-Operationen und die Integer-Registerdatei blieb immer noch eine. Später wurden Schattenregisterdateien in neueren Designs zugunsten des eingebetteten Marktes aufgegeben.

Der SPARC verwendet auch "Shadow Register File Architecture" für seine High-End-Linie. Es hatte bis zu 4 Kopien von Integer-Registerdateien (zukünftig, zurückgezogen, skaliert, verkratzt, jede mit 7 Lese- 4 Schreib-Ports) und 2 Kopien der Gleitkomma-Registerdatei. Im Gegensatz zu Alpha und x86 befinden sie sich jedoch im Backend als Rückzugseinheit direkt nach ihrer Out-of-Order-Einheit und Umbenennen von Registerdateien und laden keine Befehle während der Befehlsabruf- und Dekodierungsstufe und ein Kontextwechsel ist in diesem Design unnötig.

IBM verwendet den gleichen Mechanismus wie viele große Mikroprozessoren und führt die Registerdatei tief mit dem Decoder zusammen, aber ihre Registerdatei arbeitet unabhängig von der Decoderseite und beinhaltet keinen Kontextwechsel, was sich von Alpha und x86 unterscheidet. Die meisten seiner Registerdateien dienen nicht nur seinem dedizierten Decoder, sondern bis auf Thread-Ebene. Zum Beispiel hat POWER8 bis zu 8 Befehlsdecoder , aber bis zu 32 Registerdateien mit jeweils 32 Universalregistern (4 Lese- und 4 Schreibports), um gleichzeitiges Multithreading zu erleichtern , dessen Befehl nicht über andere Registerdateien hinweg verwendet werden kann (fehlen des Kontextwechsels.).

In der x86- Prozessorlinie hatte eine typische CPU vor 486 keine individuelle Registerdatei, da alle Universalregister direkt mit ihrem Decoder arbeiteten und der x87-Push-Stack sich innerhalb der Gleitkommaeinheit selbst befand. Ab Pentium ist ein typischer Pentium-kompatibler x86-Prozessor mit einer Kopie der Single-Port-Architekturregisterdatei mit 8 Architekturregistern, 8 Steuerregistern, 8 Debug-Registern, 8 Bedingungscoderegistern, 8 unbenannten Registern und einem Befehlszeiger integriert , ein Flagregister und 6 Segmentregister in einer Datei.

Eine Kopie des 8 x87 FP Push-Down-Stack, standardmäßig wurden MMX- Register virtuell vom x87-Stack simuliert und erfordern x86-Register, um MMX-Befehle und Aliase zu liefern, um Stack zu liefern. Auf P6 kann der Befehl in frühen Pipeline-Stufen unabhängig gespeichert und parallel ausgeführt werden, bevor er in Mikrooperationen dekodiert und bei einer Ausführung außerhalb der Reihenfolge umbenannt wird. Beginnend mit P6 benötigen alle Registerdateien keinen zusätzlichen Zyklus, um die Daten zu verbreiten Byte). Die Registerdatei selbst bleibt immer noch eine x86-Registerdatei und ein x87-Stack und beide dienen als Auslagerungsspeicher. Seine x86-Registerdatei wurde auf Dual-Portierung erhöht, um die Bandbreite für die Ergebnisspeicherung zu erhöhen. Register wie Debug/Bedingungscode/Steuerung/unbenannt/Flag wurden aus der Hauptregisterdatei entfernt und in einzelne Dateien zwischen dem Mikro-Op-ROM und dem Befehlssequenzer platziert. Nur unzugängliche Register wie das Segmentregister werden jetzt von der Universalregisterdatei getrennt (außer dem Befehlszeiger); sie befinden sich nun zwischen dem Scheduler und dem Instruction Allocator, um das Umbenennen von Registern und die Ausführung außerhalb der Reihenfolge zu erleichtern. Der x87-Stack wurde später mit der Gleitkomma-Registerdatei zusammengeführt, nachdem ein 128-Bit-XMM-Register in Pentium III eingeführt wurde, aber die XMM-Registerdatei befindet sich immer noch getrennt von x86-Integer-Registerdateien.

Spätere P6-Implementierungen (Pentium M, Yonah) führten die "Shadow Register File Architecture" ein, die auf 2 Kopien einer Dual-Ported Integer-Architektur-Registerdatei erweitert wurde und aus einem Kontextwechsel besteht (zwischen zukünftigen und zurückgezogenen Dateien und skalierten Dateien mit dem gleichen Trick, der zwischen Integer und Floating verwendet wurde) Punkt). Es war, um den Registerengpass zu lösen, der in der x86-Architektur nach der Einführung der Mikro-Op-Fusion besteht, aber es hat immer noch 8 Einträge 32-Bit-Architekturregister für eine Gesamtkapazität von 32 Byte pro Datei (Segmentregister und Befehlszeiger bleiben in der Datei). , obwohl sie für das Programm nicht zugänglich sind) als spekulative Datei. Die zweite Datei dient als skalierte Schattenregisterdatei, die ohne Kontextwechsel die skalierte Datei einige Befehle nicht unabhängig speichern kann. Einige Befehle von SSE2/SSE3/SSSE3 erfordern diese Funktion für Ganzzahloperationen, zum Beispiel Befehle wie PSHUFB, PMADDUBSW, PHSUBW, PHSUBD, PHSUBSW, PHADDW, PHADDD, PHADDSW würden das Laden von EAX/EBX/ECX/EDX aus beiden Registerdateien erfordern. obwohl es für den x86-Prozessor ungewöhnlich war, eine andere Registerdatei mit demselben Befehl zu verwenden; Meistens wird die zweite Datei als eine zurückgezogene Datei für die Waage bereitgestellt. Die Pentium-M-Architektur bleibt immer noch eine Dual-Port-FP-Registerdatei (8 Einträge MM/XMM), die mit drei Decodern geteilt wird, und das FP-Register hat keine Schattenregisterdatei mit sich, da ihre Schattenregisterdateiarchitektur keine Gleitkommafunktion enthält. Prozessor nach P6, die Architekturregisterdatei ist extern und befindet sich im Backend des Prozessors nach dem Ausscheiden, im Gegensatz zu der internen Registerdatei, die sich im inneren Kern für den Registerumbenennungs-/Neuordnungspuffer befindet. In Core 2 befindet es sich jedoch jetzt in einer Einheit namens "Register-Alias-Tabelle" RAT, die sich mit dem Instruktionszuordner befindet, aber die gleiche Registergröße wie der Rückzug hat. Core 2 vergrößerte den inneren Ringbus auf 24 Bytes (ermöglichen die Decodierung von mehr als 3 Befehlen) und erweiterte seine Registerdatei von Dual Ported (einmal Lesen/einmal Schreiben) auf Quadported (zweimal Lesen/zwei Schreiben), Register bleiben immer noch 8 Einträge in 32 Bit und 32 Byte (ohne 6 Segmentregister und einen Befehlszeiger, da auf sie durch keinen Code/Befehl in der Datei zugegriffen werden kann) in der Gesamtdateigröße und erweitert auf 16 Einträge in x64 für eine Gesamtgröße von 128 Byte pro Datei. Von Pentium M als Pipeline-Port und Decoder erhöht, aber sie befinden sich mit Zuweisungstabelle anstelle von Codepuffer. Seine FP-XMM-Registerdatei wird ebenfalls auf Quadport erhöht (2 Lesen / 2 Schreiben), die Register bleiben immer noch 8 Einträge in 32 Bit und werden auf 16 Einträge im x64-Modus erweitert und die Anzahl bleibt weiterhin 1 da die Architektur der Schattenregisterdatei kein Floating enthält Punkt/SSE-Funktionen.

In späteren x86-Implementierungen, wie Nehalem und späteren Prozessoren, sind jetzt sowohl Integer- als auch Gleitkommaregister in einer einheitlichen octa-ported (sechs Lese- und zwei Schreib-) Universalregisterdatei (8 + 8 in 32-Bit und 16 + 16 .) enthalten in x64 pro Datei), während die Registerdatei mit verbesserter "Shadow Register File Architecture" auf 2 erweitert wurde, um Hyperthreading auszuführen, und jeder Thread verwendet unabhängige Registerdateien für seinen Decoder. Später ersetzte Sandy Bridge und später die Schattenregistertabelle und Architekturregister durch eine viel große und noch weiter fortgeschrittenere physische Registerdatei, bevor sie in den Neuordnungspuffer dekodiert wurde. Randered, dass Sandy Bridge und weiter kein Architekturregister mehr führen.

Auf der Atom- Linie befand sich die moderne vereinfachte Überarbeitung von P5. Es enthält einzelne Kopien der Registerdateifreigabe mit Thread und Decoder. Die Registerdatei ist ein Dual-Port-Design, 8/16 Einträge GPRS, 8/16 Einträge Debug-Register und 8/16 Einträge Bedingungscode sind in derselben Datei integriert. Es verfügt jedoch über ein schattenbasiertes 64-Bit-Register mit acht Einträgen und ein unbenanntes 64-Bit-Register mit acht Einträgen, die jetzt im Gegensatz zum ursprünglichen P5-Design von den Haupt-GPRs getrennt sind und sich nach der Ausführungseinheit befinden, und die Datei dieser Register ist Single-Ported und keinen Anweisungen wie der skalierten Schattenregisterdatei auf Core/Core2 ausgesetzt (Schattenregisterdateien bestehen aus Architekturregistern und Bonnell hatte keine "Shadow Register File Architecture"), die Datei kann jedoch für Umbenennungszwecke verwendet werden zu mangelnder Ausführung in der Reihenfolge der Bonnell-Architektur. Es hatte auch eine Kopie der XMM-Gleitkommaregisterdatei pro Thread. Der Unterschied zu Nehalem besteht darin, dass Bonnell keine einheitliche Registerdatei und keine dedizierte Registerdatei für das Hyper-Threading hat. Stattdessen verwendet Bonnell ein separates Umbenennungsregister für seinen Thread, obwohl er nicht außer Betrieb ist. Ähnlich wie Bonnell haben auch Larrabee und Xeon Phi jeweils nur eine Allzweck-Integer-Registerdatei, aber der Larrabee hat bis zu 16 XMM-Registerdateien (8 Einträge pro Datei) und der Xeon Phi hat bis zu 128 AVX-512-Registerdateien , die jeweils 32 512-Bit-ZMM-Register für die Vektorbefehlsspeicherung enthalten, die so groß wie ein L2-Cache sein können.

Es gibt einige andere von Intels x86-Linien, die keine Registerdatei in ihrem internen Design haben, Geode GX und Vortex86 und viele eingebettete Prozessoren, die nicht Pentium- kompatibel sind oder frühere 80x86-Prozessoren zurückentwickelt haben. Daher haben die meisten von ihnen keine Registerdatei für ihre Decoder, aber ihre GPRs werden einzeln verwendet. Pentium 4 hingegen hat keine Registerdatei für seinen Decoder, da seine x86-GPRs aufgrund der Einführung einer physischen einheitlichen Umbenennungsregisterdatei (ähnlich wie Sandy Bridge, aber etwas anders) in seiner Struktur nicht existierten aufgrund der Unfähigkeit von Pentium 4, das Register vor der Benennung zu verwenden), um zu versuchen, die Architekturregisterdatei zu ersetzen und das x86-Decodierungsschema zu überspringen. Stattdessen verwendet es SSE für die Integer-Ausführung und -Speicherung vor der ALU und nach dem Ergebnis verwenden SSE2/SSE3/SSSE3 denselben Mechanismus auch für seine Integer-Operation.

AMDs frühes Design wie K6 hat keine Registerdatei wie Intel und unterstützt keine "Shadow Register File Architecture", da das Fehlen von Kontextwechsel und Bypass-Inverter, die für eine ordnungsgemäße Funktion einer Registerdatei erforderlich sind, erforderlich ist. Stattdessen verwenden sie separate GPRs, die mit einem dedizierten Integer-Decoder und Floating-Decoder direkt mit einer Umbenennungsregistertabelle für ihre OoOE-CPU verbunden sind. Der Mechanismus ähnelt Intels Pre-Pentium-Prozessoren. Zum Beispiel hat der K6- Prozessor vier int (eine temporäre verkratzte Registerdatei mit acht Einträgen + eine zukünftige Registerdatei mit acht Einträgen + eine abgerufene Registerdatei mit acht Einträgen + eine unbenannte Registerdatei mit acht Einträgen) und zwei FP-Umbenennungsregisterdateien ( zwei x87-ST-Datei mit acht Einträgen, eine wird fadd und eine wird fmov), die direkt mit ihrem x86-EAX für die Umbenennung von Ganzzahlen und dem XMM0-Register für die Umbenennung von Gleitkomma verknüpft ist, aber später hat Athlon "Schattenregister" in sein Frontend aufgenommen, es ist auf skaliert Eine vereinheitlichte Registerdatei mit 40 Einträgen für eine ganzzahlige Operation in der Reihenfolge vor der Decodierung, die Registerdatei enthält 8 Einträge im Scratch-Register + 16 zukünftige GPRs-Registerdateien + 16 unbenannte GPRs-Registerdateien. In späteren AMD-Designs gibt es das Schattenregister-Design auf und bevorzugt die K6-Architektur mit individuellem GPRs-Direct-Link-Design. Wie Phenom verfügt es über drei int-Registerdateien und zwei SSE-Registerdateien, die sich in der physischen Registerdatei befinden, die direkt mit GPRs verknüpft ist. Bei Bulldozer wird es jedoch auf eine ganze Zahl + einen Gleitkomma herunterskaliert . Wie frühe AMD-Designs verwendeten auch die meisten x86-Hersteller wie Cyrix, VIA, DM&P und SIS denselben Mechanismus, was zu einem Mangel an Integer-Leistung ohne Registerumbenennung für ihre geordneten CPUs führte. Unternehmen wie Cyrix und AMD mussten die Cache-Größe erhöhen, um den Engpass zu reduzieren. AMDs SSE-Integer-Operation funktioniert anders als Core 2 und Pentium 4; es verwendet sein separates Umbenennungs-Integer-Register, um den Wert direkt vor der Dekodierungsstufe zu laden. Obwohl es theoretisch nur eine kürzere Pipeline als die SSE-Implementierung von Intel benötigt, sind die Kosten für die Verzweigungsvorhersage im Allgemeinen viel höher und die fehlende Rate höher als bei Intel, und es müsste mindestens zwei Zyklen dauern, bis der SSE-Befehl ausgeführt wird, unabhängig davon befehlsweit, da frühe AMD-Implementierungen nicht sowohl FP als auch Int in einem SSE-Befehlssatz ausführen konnten, wie dies bei der Implementierung von Intel der Fall war.

Im Gegensatz zu Alpha , Sparc und MIPS , die es nur einer Registerdatei erlauben, jeweils einen Operanden zu laden/abzurufen; es würde mehrere Registerdateien erfordern, um eine Superskalierung zu erreichen. Der ARM- Prozessor hingegen integriert nicht mehrere Registerdateien zum Laden/Abrufen von Befehlen. ARM-GPRs haben keinen besonderen Zweck für den Befehlssatz (der ARM-ISA benötigt keinen Akkumulator, Index und Stack-/Basispunkte. Register haben keinen Akkumulator und Basis-/Stackpunkt kann nur im Daumenmodus verwendet werden). Beliebige GPRs können mehrere Befehle unabhängig in kleinerer Codegröße ausbreiten und speichern, die klein genug ist, um in ein Register zu passen, und seine Architekturregister wirken als Tabelle und werden mit allen Decodern/Befehlen mit einfacher Bankumschaltung zwischen Decodern geteilt. Der Hauptunterschied zwischen ARM und anderen Designs besteht darin, dass ARM die Ausführung auf demselben Universalregister mit schneller Bankumschaltung ermöglicht, ohne dass eine zusätzliche Registerdatei in Superskalar erforderlich ist. Obwohl x86 den gleichen Mechanismus mit ARM teilt, dass seine GPRs alle Daten einzeln speichern können, wird x86 mit der Datenabhängigkeit konfrontiert, wenn mehr als drei nicht verwandte Befehle gespeichert werden, da seine GPRs pro Datei zu klein sind (acht im 32-Bit-Modus und 16 in .). 64-Bit, im Vergleich zu ARMs 13 in 32-Bit und 31 in 64-Bit) für Daten, und es ist unmöglich, Superskalar ohne mehrere Registerdateien zu haben, die an seinen Decoder gespeist werden (x86-Code ist im Vergleich zu ARM groß und komplex). Denn die meisten x86-Frontends sind viel größer und leistungshungriger geworden als der ARM-Prozessor, um konkurrenzfähig zu sein (Beispiel: Pentium M & Core 2 Duo, Bay Trail). Einige x86-äquivalente Prozessoren von Drittanbietern wurden sogar nicht mehr mit ARM konkurrenzfähig, da sie keine dedizierte Registerdateiarchitektur hatten. Vor allem für AMD, Cyrix und VIA, die ohne Register-Umbenennung und Out-of-Order-Execution keine vernünftige Leistung bringen können, was nur Intel Atom als einziger x86-Prozessorkern in der mobilen Konkurrenz übrig lässt. Dies geschah, bis der x86-Nehalem-Prozessor sowohl sein Integer- als auch Gleitkommaregister in einer einzigen Datei zusammenführte und eine große physische Registertabelle und eine verbesserte Zuweisungstabelle in seinem Front-End einführte, bevor er in seinem ausgefallenen internen Kern umbenannt wurde .

Umbenennung registrieren

Prozessoren, die eine Registerumbenennung durchführen , können dafür sorgen, dass jede Funktionseinheit in eine Teilmenge der physischen Registerdatei schreibt. Diese Anordnung kann die Notwendigkeit mehrerer Schreibports pro Bitzelle eliminieren, um große Flächeneinsparungen zu erzielen. Die resultierende Registerdatei, effektiv ein Stapel von Registerdateien mit einzelnen Schreibports, profitiert dann von der Replikation und der Untergliederung der Leseports. Am Limit würde diese Technik einen Stapel von 1-Schreib-, 2-Lese-Regfiles an den Eingängen jeder Funktionseinheit platzieren. Da Regfiles mit einer kleinen Anzahl von Ports oft von der Transistorfläche dominiert werden, ist es am besten, diese Technik nicht an diese Grenze zu bringen, aber sie ist trotzdem nützlich.

Fenster registrieren

Die SPARC ISA definiert Registerfenster , in denen die 5-Bit-Architekturnamen der Register tatsächlich auf ein Fenster in einer viel größeren Registerdatei mit Hunderten von Einträgen zeigen. Die Implementierung von Multiport-Registerdateien mit Hunderten von Einträgen erfordert einen großen Bereich. Das Registerfenster verschiebt sich beim Verschieben um 16 Register, sodass sich jeder Architekturregistername nur auf eine kleine Anzahl von Registern im größeren Array beziehen kann, zB kann sich das Architekturregister r20 nur auf die physischen Register #20, #36, #52, # beziehen. 68, #84, #100, #116, wenn nur sieben Fenster in der physischen Datei vorhanden sind.

Um Platz zu sparen, implementieren einige SPARC-Implementierungen eine Registerdatei mit 32 Einträgen, in der jede Zelle sieben "Bits" hat. Nur einer ist über die externen Ports lesbar und beschreibbar, aber der Inhalt der Bits kann rotiert werden. Eine Drehung bewirkt in einem einzigen Zyklus eine Bewegung des Registerfensters. Da die meisten Kabel, die die Zustandsbewegung ausführen, lokal sind, ist eine enorme Bandbreite mit wenig Leistung möglich.

Dieselbe Technik wird in der R10000- Registerumbenennungs-Zuordnungsdatei verwendet, die eine virtuelle 6-Bit-Registernummer für jedes der physischen Register speichert. In der Umbenennungsdatei wird der Umbenennungszustand jedes Mal mit einem Prüfpunkt versehen, wenn eine Verzweigung genommen wird, so dass, wenn eine Verzweigung als falsch vorhergesagt erkannt wird, der alte Umbenennungszustand in einem einzigen Zyklus wiederhergestellt werden kann. (Siehe Registerumbenennung .)

Siehe auch

Verweise

Externe Links