Details und Analyse der Zen-Architektur nach der Hot-Chips-Konferenz
Die Fetch-Einheit im Detail
Um die bereits gezeigten Ressourcen für Ausführung und Datenhaltung nicht verhungern zu lassen, hat AMD auch das sogenannte Execution Front End, also die Befehlsversorgung, gegenüber Excavator ausgebaut.
Das beginnt mit in drei Ebenen vorhandenen großen Adressübersetzungs-Spickzetteln (Translation Lookaside Buffers oder TLBs), die sowohl schnell als auch in dieser Kombination energiesparend sind. Dort werden einmal die Übersetzungen von virtuellen in physikalische Adressen von Speicherblöcken mit Programmcode für den Schnellzugriff vorgehalten. Treue Leser werden sich an die TLB-Probleme der ersten Bulldozerversion und deren Verbesserungen ab Vishera erinnern.
Ebenso erwähnenswert ist der Hash Perceptron Predictor, also eine Sprungvorhersage-Einheit, die mit Hilfe eines neuronalen Netzes das Sprungverhalten im ausgeführten Programmcode lernt und vorhersagt. Das hatten auch schon die Cat-Kerne und spätere Kerne der Bulldozer-Reihe. Bei Zen wird gibt es jedoch die Neuerung, dass das mit Hashes verknüpft wird, um die Leistung noch zu steigern. Dabei bestimmt nicht allein die aktuelle Position im Programmcode, welches Perceptron zuständig ist, sondern es wird aus der Adresse und deren bisherigen Sprunghistorie ein Hash berechnet. Das erhöht die Trefferquote nochmals.
Der 32 Einträge große Return Stack Puffer ist wichtig für die immer tiefer verschachtelten Aufrufe heutiger Software und Betriebssysteme. Das Indirect Target Array unterstützt dagegen z. B. bei virtuellen Funktionsaufrufen oder Sprungtabellen in Switch-Case-Anweisungen (für die Programmierer unter uns).
Der mit 64 KiB (4‑wegig) ausreichend dimensionierte Level-1-Befehlscache sollte auch mit zwei Threads im SMT-Betrieb nicht so schnell Engpässe aufkommen lassen. Bei der Bulldozer-Reihe, wo das Front End ebenfalls zwei Threads abarbeiten konnte, betrug die Größe dieses Cache anfangs auch 64 KiB (indes nur 2‑wegig), welche später auf 96 KiB (3 Wege) ab Steamroller aufgestockt wurden. Zudem gibt es bei Bulldozer im Zusammenspiel mit einem Linux-Sicherheitsfeature (ASLR) Probleme, wo der im Cache liegende Programmcode bei bestimmten Kombinationen von Speicheradressen zweier oder mehrerer Programme gegenseitig wieder aus dem Cache geworfen wurde.
Nachdem eine Adresse ermittelt und in die Physical Request Queue für das Laden des nächsten Programmcodes aus dem Level-1-Befehlscache eingereiht wurde, wird parallel über ein kleines Tag (µTag) geprüft, ob die gewünschten Befehle schon im MOp-Cache vorliegen. Liefert das µTag für den MOp-Cache keinen Treffer, werden die Befehle in einem 32 Byte-Block aus dem L1-Befehlscache geladen und an die Decoder-Einheit weitergereicht.