Zum Hauptinhalt Zur Navigation

Kerne im Detail verbessert

Bei den Prime-Kernen decodiert das Frontend pro Takt neun Befehle, einen mehr als der Vorgänger und AMDs Zen-5-Kerne (g+) sowie Panther Lakes Cougar-Cove-P-Cores. Am ähnlichsten erscheinen uns die Darkmont-E-Cores des kommenden Intel-Prozessors, deren Frontend ebenfalls neun Befehle pro Takt decodieren kann. Die erreicht es nicht immer, allerdings kann x86-Code, da es sich um eine CISC-Architektur (Complex Instruction Set Computer) handelt, eine höhere Code-Dichte erreichen.

Die Sprungvorhersage (g+) übernehmen gleich drei Strukturen. Ohne Verzögerung arbeitet der Branch Target Buffer (BTB). Die Prediktoren für bedingte und indirekte Sprünge brauchen jeweils zwei Takte für eine Vorhersage und führen zu einer Verzögerung von einem Takt. Auch ein Return Stack für Rücksprungadressen ist vorhanden, allerdings erfahren wir keine Details zum Aufbau und Fassungsvermögen dieser Einheiten. Ein falsch vorhergesagter Sprung bedeutet eine Verzögerung von 13 Takten, wie beim Vorgänger.

Allein anhand des Frontends lässt sich kaum ein Leistungsvergleich ziehen, zumal hier noch andere Komponenten eine Rolle spielen: etwa der mit 192 kByte auffällig große, sechsfach assoziative Befehls-Cache (L1i), aus dem das Frontend pro Takt 16 Befehle (64 Byte) lesen kann – doppelt so viele wie der Vorgänger. Der Translation-Lookaside Buffer (TLB) für Adressübersetzungen ist zweistufig, Stufe zwei wird für Befehle und Daten geteilt genutzt. Der L1i TLB hat 256 Einträge und ist achtfach assoziativ, der L1d TLB ist mit 224 Einträgen und siebenfacher Assoziativität etwas kleiner.

Der L2 TLB fasst 8.192 Einträge, ist achtfach assoziativ, hier dauert ein Zugriff allerdings zwei Takte, während es bei den L1-TLBs ein Takt ist. Wird eine Adressübersetzung nicht in einem der TLBs gefunden, übernimmt der Table Walker, der bis zu 16 Übersetzungen gleichzeitig bearbeiten kann. Zwischenschritte werden gecached, da die Adressübersetzung mit einer Granularität von 4 oder 64 kByte arbeitet. Größere Seiten können entsprechend mehrere Übersetzungsvorgänge erfordern.

Integer- und Vektoreinheit können viel umsortieren

Die neun Befehle aus dem Frontend ziehen sich bei den Oryon-Kernen durch das gesamte Design: Es sind ebenso viele Einheiten für Register Renaming vorhanden (Abbildung auf physische Register für Out-of-Order-Execution, g+ ). Zudem können neun Befehle pro Takt abgeschlossen werden (Retire).

Manche andere Architekturen nutzen weniger Einheiten, da das Frontend nicht immer die maximale Anzahl an Mikrooperationen liefert. Es spielt eine Rolle, in wie viele Mikrooperationen Befehle im Mittel übersetzt werden, bei den Oryon-Kernen wird aus den meisten ARM-Befehlen eine Mikrooperation. Allerdings ist auch weniger möglich, da das Frontend manche Mikrooperationen zu einer kombinieren kann (μOp Fusion).

Ebenfalls nicht alltäglich ist, dass Integer- und Vektoreinheit ungefähr gleich viele physische Register zur Verfügung stehen. Genau können wir das nicht sagen, da Qualcomm lediglich von jeweils über 400 spricht. Den Integer-Einheiten stehen damit deutlich mehr Register zur Verfügung als bei Zen 5 mit 240, während bei den Vektorregistern nur die Zahl höher ist – ein Zen-5-Kern verfügt über 384 physische Register, die mit 512 Bit viermal so breit sind wie bei Oryon.

Die vier Vektoreinheiten unterstützen alle Fused-Multiply-Accumulate (FMA), Divisionen hingegen nur eine. Neben den IEEE-754-Datentypen (FP16, FP32 und FP64) wird BF16 unterstützt. Von den Integer-Einheiten unterstützen lediglich zwei FMA und eine Divisionen. Der Kern erlaubt maximal 192 ausstehende Lese- und 56 Schreibbefehle.

Großes Out-of-Order-Fenster

Für jede Ausführungseinheit steht eine Reservation Station zur Verfügung, die für die Integer-Einheiten jeweils 20, für die Vektoreinheiten sogar 48 Befehle fassen. Das dürfte zwei Gründe haben: Während die Integer-ALU fast alle Operationen in einem Takt abarbeitet (Multiplikationen brauchen drei, für Divisionen nennt Qualcomm keinen Wert), dürften die Vektoreinheiten für die Gleitkomma- und kryptographischen Operationen länger brauchen. Zudem arbeiten sie mit 128-Bit-Werten, die Integer-Einheiten mit 64 Bit. Entsprechend könnten Vektoroperationen länger auf Daten warten.

Den Reorder Buffer, der die umsortierten Befehle wieder in die Programmreihenfolge bringt, teilen sich Integer- und Vektoreinheit. Er fasst über 650 Mikrooperationen, beim Vorgänger hatte er laut Chips and Cheese 680 Einträge. Auch hier dürfte sich nichts geändert haben, da Qualcomm auch beim Snapdragon X Elite von 650+ Einträgen sprach.

Zu den Reservation Stations für Vektor- und Integer-Einheiten kommen vier für Speicherzugriffe, pro Takt sind je zwei 128-Bit-Lese- und -Schreiboperationen möglich. In Qualcomms Präsentation ist allerdings von 14+ Reservation Stations zu lesen – welche uns das Unternehmen verschweigt, ist nicht klar. Eventuell ist damit auch gemeint, dass die Architektur noch breiter skaliert werden könnte.

Abgesichert gegen Angriffe

Bevor wir zu den geteilt genutzten Einheiten der Kern-Cluster kommen, schauen wir uns noch die Sicherheitsmechanismen an: Die Oryon-Kerne sollen gegen alle bekannten Seitenkanalangriffe der vergangenen Jahre immun sein. Neben ARMs Trustzone sind eine Reihe von Sicherheitsmaßnahmen implementiert: Spekulationsbarrieren sollen verhindern, dass die spekulative Code-Ausführung in Bereiche kommt, die sie nicht erreichen sollte, Pointer Authentication und Brach IDs sicherstellen, dass Code die vorgesehenen Pfade nimmt. Memory Tagging soll beim Erkennen von Speicherzugriffsfehlern helfen.

Die Hardware für Sprungvorhersagen verschleiert zudem ihre Funktion mittels kryptographischer Blockchiffren, was Seitenkanalangriffe zumindest deutlich erschweren soll. Für qualitativ hochwertige Zufallszahlen soll zudem ein Hardware-Zufallszahlengenerator sorgen, den sich die Kerne eines Clusters teilen. Und damit sind wir bereits bei der geteilten Hardware.


Relevante Themen