Der Intel Pentium 4. Architektur Teil 1. Fatih Gürsoy Betreuender. Datum: Januar 2003

Transkript

1 Architektur Teil 1 Von: Semester: Vorlesung: Betreuender Hochschulprofessor: I8I1x Rechnerstrukturen Prof. Dr. T. Risse Datum: Januar 2003

2 Inhaltsverzeichnis: 1 Einleitung Allgemeines zum Intel Pentium Architektur des Pentium Der neue Prozessorbus Advanced Transfer Cache Hardware Data Prefetch Das Frontend... 7 Instruction Translate Look-aside Buffer ITLB... 7 Dynamic Branch Predictor und Trace Cache Branch Prediction (BTB)... 8 Branch Target Buffer (BTB)... 9 Micro Code ROM... 9 Instruction Decoder Execution Trace Cache L1-Daten Cache Quellen: Seite 2 -

3 1 Einleitung Im Rahmen der Vorlesung Rechnerstrukturen wurden sog. Assignments erarbeitet. Dabei ging es in unserer Gruppe um den Intel Pentium 4. In der Folgevorlesung Rechnerstukturen-Labor soll nun im Wesentlichen die Speicheranbindung des Intel Pentium 4 genauer betrachtet werden. Vorab werden die wesentlichen Neuerungen des Pentium 4 kurz angerissen, aber nicht vertieft. Dieses ist nur um den Pentium 4 kurz vorzustellen. 2 Allgemeines zum Intel Pentium 4 Mit dem Pentium 4 führte Intel erstmals die NetBurst TM -Architektur[1] ein. Mit NetBurst stellt Intel ein ganz neues Prozessordesign vor. Taktfrequenzen ab 1,4 GHz und Skalierbarkeit für viele Jahre sollen als Erfolgsgarant dienen. NetBurst ist der Sammelbegriff für eine Vielzahl von Neuerungen, die erstmals beim Pentium 4 Einzug halten. NetBurst beinhaltet: 400 MHz Systembus Advanced Transfer Cache Trace Cache Hyper-Pipeline Rapid Execution Engine Advanced Dynamic Execution SSE2 - Seite 3 -

4 3 Architektur des Pentium 4 Bild 1: Architektur des P4 [2] Folgende Neuerungen erhalten Einzug in den Pentium 4: 400 MHz System-Bus: Der Pentium 4 erlaubt Datentransferraten von ~ 3 GByte/s und verfügt somit über die dreifache Bandbreite des Pentium III mit 133-MHz-FSB. Advanced Transfer Cache: Die Größe des Advanced Level 2 Transfer Cache beträgt 256 KB (Willamette) und liefert einen wesentlich höheren Datendurchsatz zwischen dem Level 2 Cache und dem Core. Der Advanced Transfer Cache besteht aus einem 256-Bit (32-Byte) Interface welches Daten zu jeder Core-Clock transferiert. Z.B. Ein Pentium 4 mit 1,5 GHz kann eine Transferrate von 48 GB/s (32 Bytes x 1 (Datentransfer pro Clock) x 1,5 GHz = 48 GB/s). Trace-Cache: Der Trace Cache ist ein erweiterter L1-Cache für Befehle. Er speichert bereits dekodierte x86-befehle (µops). Wartezeiten durch Befehlsdekodierung beim Speisen der Pipeline werden verhindert, da die Pipeline fertig dekodierte x86-befehle (µops)vom Trace Cache bekommt. - Seite 4 -

5 Hyper-Pipeline: Mit 20 Stufen doppelt so lang wie beim P6-Core. Sie kann bis zu 128* Micro-Ops gleichzeitig verarbeiten. Die Hyper-Pipeline-Technologie ermöglicht die hohen Taktfrequenzen des Pentium 4. Rapid Execution Engine: Die ALUs des Pentium 4 takten mit der doppelten Core- Frequenz. Integer-Befehle bearbeitet NetBurst damit beim 1,5 GHz Pentium 4 mit 3 GHz. Advanced Dynamic Execution: Sehr tiefe Core-Architektur nach dem spekulativen Out-of-Order Prinzip. NetBurst kann 126* Befehle gleichzeitig halten und stellt das Befehlsfenster den Ausführungseinheiten zur Verfügung. Zusätzlich verfügt der Pentium 4 über eine verbesserte Sprungvorhersage, die bei langen Pipelines sehr wichtig ist. Unterstützt wird die Sprungvorhersage durch einen 4 KByte großen Branch Target Buffer. SSE2: Die Streaming SIMD Extensions 2 verfügen über 144 neue Befehle und erlauben 128 Bit breite Integer- und Floating-Point-Operationen. Die Hyperpipeline, Rapid Execution Engine, Advanced Dynamic Execution sowie die SSE2 Befehle werden im zweiten Teil von Carsten Siebert und Beatrice Pop ausführlich behandelt. 3.1 Der neue Prozessorbus Bild 2: Der Prozessorbus Beim Pentium 3 ist der FSB mir 133 MHz getaktet und ist in der Lage, 64-Bit Daten mit einem Taktzyklus zu übertragen. Das ergibt eine Transferrate von 8 Byte * 133 MHz/s = 1,066 MB/s. * Die unterschiedlichen Angaben resultieren daraus, dass die genaue Größe der Micro-Ops nicht bekannt ist - Seite 5 -

6 Der Pentium 4 Bus wird mit 100 MHz beim Willamette und 133 MHz beim Northwood getaktet. Die Busbreite ist gleich geblieben. Es werden beim Pentium 4 nur pro Takt vier Datenwörter übertragen. 8 Byte * 4 * 133 MHz/s = 4,2 GB/s. Intel nennt das Übertragen von vier Datenwörtern Quad Pumped Bus [5]. Das Übertragen von 4 Datenwörtern setzt zwei Kanäle voraus. Einen für Read- und einen für Write-Operationen. Des Weiteren findet jeden halben Takt eine Datenübertragung statt. Dieser schnelle Datenaustausch verhindert den Engpass, der bis zum Pentium 3 noch präsent war. Vorausgesetzt der Hauptspeicher kann die Daten schnell genug liefern. 3.2 Advanced Transfer Cache Bild 3: Advanced Transfer Cache, Hardware Data Prefetch und L1 Data Cache Der Name Advanced Transfer Cache (L2) kommt noch vom Pentium 3 Coppermine. Er ist beim Willamette mit 256 KB und beim Northwood mit 512 KB angegeben. Die einzige Gemeinsamkeit zum Pentium 3 ist noch, dass es 8-Fach Satz assoziative Caches sind. Beim Pentium 4 wurde die Cacheline von 64-Byte auf 128-Byte erhöht, die in 2*64- Byte unterteilt wurde. Wenn der L2-Cache nun vom System (RAM, PCI, AGP, ) Daten erhält, werden auf einmal 64-Byte übertragen. Die Latenzzeit zum Lesen aus dem L2 beträgt 7 Cycles (bis die Daten vollständig an L1-Cache, oder an den x86 Instruction decode/prefetch Buffern anstehen). Die Verbindung zum Core ist 256-Bit breit und wird mit vollem Prozessortakt getaktet. Um eine L2-Cache-Line zu füllen, werden vier Taktzyklen benötigt, genau so viele Taktzyklen wie der P6-Bus für eine 32-Bit-Line. 3.3 Hardware Data Prefetch Das streaming Bit vom SSE ist für die prefetch-instuctoins des Pentium 3. Dieses Bit ermöglicht Software, sofern diese Bit gesetzt ist, Daten in die Caches zu laden, bevor sie von der CPU benötigt werden. Das setzten des Bits erfolgt Softwareseitig. - Seite 6 -

7 Diese Instruktionen sind beim Pentium 4 geblieben. Diese neue Einheit (siehe Bild 3) ist nun in der Lage, Datenzugriffs-Muster von Software, die durch den Pentium 4 ausgeführt wird, zu erkennen. Erkennt nun die Hardware Data Prefetch Unit, dass immer fortlaufende Streaming-Daten am L1 ankommen, werden sie automatisch prefetcht. Das setzen eines Bits durch die Software ist jetzt nicht mehr notwendig. Wie das Erkennen der fortlaufenden Streaming-Daten erfolgt, darüber schweigt Intel. 3.4 Das Frontend Das Frontend ist der Teil der Maschine, der die nächsten Befehle, die ausgeführt werden sollen, holt und sie für die Verarbeitung bereitstellt, um diese später in der Pipeline zu benutzen. Das Frontend hat dabei eine sehr exakte Branch Prediction Logik, die die vorhergesagten Sprungziele der Befehle abspeichert. Dadurch kann man bei der nächsten Berechnung des Sprungzieles spekulieren, wo das Programm hin verzweigen wird. Diese vorrausgesagte Sprungzieladresse von der Branch Prediction Einheit wird benutzt, um die nächsten Befehle vom L2 Cache zu holen. Diese x86-befehle werden dann in einfachere Befehle dekodiert, die µops genannt werden. Die NetBurst-Mikroarchitektur hat einen erweiterten L1-Instruction Cache, der Execution Trace Cache genannt wird. Dort werden diese µops gespeichert und somit entfällt bei der erneuten Ausführung des Befehls das Dekodieren. Die Prefetch- Logik bekommt schon fertig dekodierte x86-befehle, die sog. µops. Bild 4: Frontend des Pentium 4 Instruction Translate Look-aside Buffer ITLB Bei einem Trace Cache Miss muss der nächste Befehl aus dem L2 geladen werden. Da der L2 Cache mit virtuellen Adressen arbeitet, müssen diese Adressen in physikalische umgewandelt werden. Der Instruction TLB hat die Aufgabe, diese virtuellen Adressen in physikalische Adressen umzuwandeln. Es beschleunigt den Speicherzugriff, da die physikalischen Adressen im TLB in einer Tabelle zwischengespeichert werden. - Seite 7 -

8 Dynamic Branch Predictor und Trace Cache Branch Prediction (BTB) Es ist unbedingt notwendig, gute Branch Predictions zu erzielen, um falsche Sprungvorhersagen zu vermeiden. Dabei wird versucht, aus dem Verhalten eines bestimmten Sprunges, eine Vorhersage für diesen Sprung herzuleiten. Im Folgenden soll kurz erläutert werden, auf welche Weise Branch Predictions [3] realisiert werden: Es gibt drei Arten von Branches: Forward Conditional Branches: Der Programm-Counter (PC) zeigt zu einer Folgeadresse im Instruktionsfluss. Backward Conditional Branches: Der PC zeigt auf eine vorhergehende Adresse im Instruktionsfluss. Die Verzweigung basiert auf einer Bedingung, wie z.b. Springe zurück zum Anfang der Programmschleife, wenn am Ende der Schleife der Schleifenzustand es erfordert, die Schleife erneut aufzurufen. Unconditional Branches: Diese Verzweigungen beinhalten Sprünge, Prozeduraufrufe und Returns, die keine spezifische Bedingung haben. Ein jmp wäre dafür ein Beispiel. Realisierung von Branch Predictions: Static Prediction: Durch Untersuchungen von durchschnittlichem Befehlscode kann man feststellen, dass z.b. vorwärts gerichtete Verzweigungen rückwärts gerichtete Verzweigungen mit dem Verhältnis 4 zu 1 dominieren. Außerdem werden nur 60% der vorwärts gerichteten Verzweigungen genommen, während dessen durchschnittlich 85% der rückwärts gerichteten Verzweigungen genommen werden (aufgrund vom Programmschleifen). Dadurch hat man statische Voraussagen für Verzweigungen in Programmabläufen. Dynamic Prediction mit Branch History Table (BHT): Den Hauptteil der Vorhersage-Arbeit leistet die Fetch-Unit in Zusammenarbeit mit dem BTB (Branch Target Buffer). Der BTB ist eine Art Cache mit 4096 Einträgen. Wird ein bedingter Sprungbefehl in der Execution-Phase der Pipeline ausgeführt, so werden in den BTB Eintragungen für diesen Befehl vorgenommen (an welcher Adresse steht dieser Verzweigungsbefehl, wurde die Verzweigung durchgeführt, wohin wurde verzweigt). Zusätzlich sind für jeden Eintrag 4 History-Bits vorhanden, die ähnlich einem Zähler verwendet werden. In diesen Bits wird festgehalten, welches Verhalten dieser bedingte Sprungbefehl ausweist, wenn er wiederholt ausgeführt wird. Vereinfacht ausgedrückt funktioniert die Vorhersage nun etwa so: wurde der bedingte Sprung in letzter Zeit eher ausgeführt, wird das auch für die nächste Ausführung angenommen und umgekehrt. Die dynamische Verzweigungsvorhersage wird bereits in der Fetch- Unit verwendet. Two-Level Predictors (z.b. GShare Algorithm): Das ist die komplexeste Möglichkeit, noch höhere Genauigkeit bei der Branch Prediction zu erreichen. Es - Seite 8 -

9 geht im groben darum, durch Ausnutzung der Korrelation aller (globalen) Verzweigungen, noch treffsicherer Voraussagen treffen zu können. Es werden Muster von Entscheidungen (T=Taken T, N=Not Taken) aufgezeichnet und zur Vorhersage herangezogen. ein einzelner Branch Befehl: z.b. Schleife TTTNTTTN Oder als alternative eine if then else Anweisung TNTNTN Korrelation zwischen verschiedenen zusammenhängenden Branch-Befehlen z.b. if then else in schleife TT NT TT NT TN TT NT TT NT TN Eine Implementation dieser Methode ist GShare-Algorithmus. Branch Target Buffer (BTB) Bild 5: Branch Target Buffer Hier werden in einer Tabelle die Adressen von vorhergehenden Verzweigungen mit den vorausgesagten Verzweigungszielen abgespeichert (optional mit Setzen von Bits, wenn diese Verzweigungen in der Vergangenheit erfolgten oder nicht). Nun ist es möglich, vor dem Instruction Decoder Adressen mit dieser Tabelle zu vergleichen und bei Übereinstimmung die entsprechend vorausgesagten Befehle der Verzweigung in den Cache zu laden. Micro Code ROM Neben Trace Cache ist das Micro Code ROM, welches die komplexen x86-befehle in µops dekodiert. Diesen Micro Code ROM findet man in vielen modernen superskalaren und uralten µ-programmierbaren Prozessoren. Das Micro Code ROM wird für komplexe IA-32 Instruktionen (x86-befehle), wie z.b. String move, Fehler- und Interruptbehandlung benutzt. Wenn ein komplexer Befehl ansteht, wird dieser von dem Micro Code Sequencer entgegengenommen. Der Micro Code Sequencer generiert die µops und liefert sie an den Trace Cache. Die µops, die aus dem Trace Cache und dem Micro Code ROM kommen, werden in einer einfachen in-order µop queue gepuffert. Dieses hilft den Fluss der µops zur Ausführungseinheit zu gewährleisten. - Seite 9 -

10 Instruction Decoder Der Instruction Decoder empfängt die x86-befehls Bytes vom L2 Cache und dekodiert diese in einfache Befehle (RISC-Befehle), damit sie weiter verarbeitet werden können. Der einfache Instruction Decoder dekodiert dabei einen x86-befehl pro Takt. Einige x86-befehle werden in einen µop dekodiert, andere wiederum in mehrere µops, um den Befehl komplett auszuführen. Wenn mehr als 4 µops dekodiert werden müssen, um einen x86-befehl auszuführen, wird dieser x86-befehl an den Micro Code ROM geschickt. Dort werden die µops generiert und weitergeleitet. Ein Beispiel wäre string move, wo tausende von µops generiert werden. Viele x86-befehle brauchen jedoch nicht den Micro Code ROM. Aus einem AND, OR, XOR oder ADD wird nur ein µop generiert, der dann direkt in den Trace Cache weitergeleitet wird. Execution Trace Cache Der Execution Trace Cache [1] oder der L1-Instruktions Cache hat gegenüber dem Pentium 3 einige Vorteile. Beim Pentium III werden die Instruktionen vom L1-Instruktions-Cache geladen und dort gespeichert, bis die Decodereinheit diese übersetzt und an die Execution Unit weiter gibt. Die Decodereinheit übersetzt den Befehl in µops, damit die Ausführungseinheiten diese verarbeiten können. Die x86-instruktionen sind relativ komplex und der Dekoder benötigt eine gewisse Zeit, um diese in µops zu übersetzen. Im schlimmsten Fall sind alle Dekoder damit beschäftigt, den x86-befehl zu übersetzen, und dieses bremst die Execution Pipeline. Ein weiterer Nachteil ist, dass die x86-befehle, die mehrmals übersetzt werden müssen (z.b. in kleinen Schleifen), immer wieder neu dekodiert werden müssen (durch den Instruktion Decoder oder dem Micro Code ROM). Der Execution Trace Cache liefert 3 µops pro Takt an die Execution Einheit. Die meisten Befehle werden von dem Trace Cache geholt und ausgeführt. Es sei denn, der auszuführende Befehl liegt nicht in dem Trace Cache (Trace Cache Miss). Dann wird der Befehl von der NetBurst Mikroarchitektur aus dem L2 Cache geholt und dekodiert. Der Execution Trace Cache kann bis zu µops speichern, was ca. 100 KByte entspricht. Intel gibt die Größe des Execution Trace Caches nur in µops an und schweigt über die Größe in KByte. Doch wenn man die Fläche des L2-Caches und die des L1 (siehe Bild 6) vergleicht, so vermutet man eine Kapazität von ca. 100 KByte. Das ist immerhin 6 mal größer als beim Pentium III (16 KByte). - Seite 10 -

11 Bild 6: Durch den Vergleich des L1 (Execution Trace Cache) und des L2 Caches schätzt man die Größe des Execution Trace Caches auf ca. 100 KByte. Der Trace Cache hat auch gewisse Vorteile bei einer falsch vorhergesagten Verzweigung. Der Prozessor muss zwar alles verwerfen, aber der Trace Cache hat eine gute Chance, auch den alternativen Pfad schon fertig dekodiert vorrätig zu halten. Um Sprünge zu optimieren, greift der Cache auf eine eigene Sprungvorhersageneinheit auf µop-basis zurück, die zusätzlich und unabhängig von der normalen x86-vorhersageneinheit arbeitet. Diese Einheit soll, laut Intel, mit einem neuen Algorithmus arbeiten, welcher die falschen Vorhersagen (Mispredictions) um 1/3 besser voraussagt als beim Pentium III [6]. Der Execution Trace Cache nimmt die dekodierten µops vom Instruction Decoder und bildet daraus eine Sequenz von µops. Diese werden dann Traces genannt. D.h. ein Trace ist eine Aneinderreihung von µops, die als nächstes verarbeitet werden. Der Execution Trace Cache bildet dabei eine Gruppe von 6 µops, die Traceline genannt wird. Diese werden wiederum zu Blöcken zusammengefasst, welche nicht durch Verzweigungen unterbrochen werden. Ein Block beginnt also nach einem Sprung oder an einem Sprungziel und enthält alle Instruktionen bis einschließlich des nächsten Sprunges. Auch die Größe eines µops gibt Intel nicht bekannt. Aber durch die Größe des Trace Caches von ca. 100 KByte und µops kann man die Größe ungefähr berechnen. 100 KByte / µops = 8 Byte 64 bit breit ist ein µop - Seite 11 -

12 L1-Daten Cache Der 8 KByte große Level1-Daten-Cache wird für das Laden und Speichern von Integer/ Floating-Point (SSE)-Werten benutzt. Im Gegensatz zum Pentium III(16 KByte) ist der Daten Cache im Pentium 50% kleiner. Es ist ein 4-fach assoziativer Cache und arbeitet nach der Write Through Strategie. D.h., beim Schreibzugriff wird grundsätzlich der L2-Cache aktualisiert. Durch die dual-port-architektur ist es möglich, pro Takt einmal zu laden und zu speichern. Die Latenzzeit beim Laden eines Integer-Werts beträgt 2 Takte und das Laden eines floatingpoint/sse-wertes 6 Takte. Der Grund ist, dass ein Integerwert 32 Bit und ein SSE-Wert 128 Bit lang ist, was natürlich länger dauert. - Seite 12 -

13 4 Quellen: Internet: [1] [2] Intel s new Pentium 4 Processor [3] PC Processor Microarchitecture A closer look at branch prediction [4] Pentium 4 Architecture in Depth, Part 1+2 [5] Quad Data Rate SRAM-Technology Zeitschriften: [6] C t 24/00 S. 124 Die Architektur des Pentium 4 im Vergleich zu Pentium III und Athlon - Seite 13 -