Startseite > Hardware > ARM Cortex-A73 toppt High-End-CPUs

»Artemis« zu gut für Konkurrenz?

ARM Cortex-A73 toppt High-End-CPUs

14. Dezember 2016, 17:09 Uhr | Lars Bube

Fortsetzung des Artikels von Teil 3

µOps zusammengeführt – x86 lässt grüßen

Wie eingangs erwähnt, enthält der Cortex-A73 nur noch zwei Befehlsdecoder (diese können neben ARMv8- auch ARMv7- und Thumb-Instruktionen verarbeiten), gefolgt von der bei Out-of-Order-Architekturen notwendigen Registerumbenennungsstufe, die einen Flaschenhals darstellt, da sie auf einen Durchsatz von zwei μOps/Taktzyklus limitiert ist (Bild 4). Um diesem Problem Herr zu werden, hat ARM zum einen die Anzahl der in µOPs gesplitteten Instruktionen reduziert und zum anderen die sogenannte μOp-Zusammenführung eingeführt, die es bei x86-Prozessoren schon lange gibt. Dabei werden gewisse µOps zu einem µOp zusammengefasst und bis zu den Ausführungseinheiten als ein Eintrag z. B. im Reorder-Puffer geführt. Um es zu ermöglichen, die Befehle in ein bis zwei Taktzyklen zu decodieren, war laut ARM die Einführung von separaten Ausführungseinheiten für Laden und Speichern unabdingbar.

Ein wesentlicher Unterschied zu Cortex‘ A15, A57 und A72 ist die Nutzung eines physikalischen Registersatzes. Die ersten drei genannten arbeiten mit Architektur-Registersätzen, die dynamisch auf die physikalischen Register abgebildet werden müssen. Der physikalische Registersatz ermöglichte beim A73 Vereinfachungen bei der Registerumbenennungsstufe für höhere Rechenleistung bei geringerer Leistungsaufnahme. Wie beim A17 wird auch ein zumindest theoretisch unbegrenztes Out-of-Order-Ausführungsfenster ermöglicht (praktisch gibt es Limitierungen). ARM nennt diese Veränderung einen »signifikaten philisophischen Wechsel beim Ansatz einer Out-of-Order-Mikroarchitektur«.

Ein verbesserter Algorithmus soll dazu für eine Optimierung bei den Ausführungswarteschlangen bzw. bei der Verteilung der Instruktionen in diese sorgen. Der Arbiter, welcher die Reihenfolge der Abarbeitung bestimmt, kann diese auf Basis von bestimmten Ereignissen on-the-fly verändern. Als Beispiel sei das Speichern eines Datenstroms genannt. Wird ein solcher erkannt, werden alle Speicheroperationen in-Order ausgeführt, damit beim Zugriff auf den Speicher eine vollständige Cache-Zeile geschrieben werden kann.

Im Backend sind die Gleitkomma-/NEON-Vektor-Einheiten gegenüber dem Cortex-A72 funktionell im Wesentlichen gleich geblieben (native 128-bit-Operationen im Gegensatz zum A17, der nur zwei 64-bit-Einheiten hatte, für die 128-bit-Operanden in zwei Teile gesplittet werden müssen), wobei der Flächenbedarf gesenkt werden konnte. Die große Veränderung findet sich, wie oben schon angedeutet, im Integer-Teil: Statt wie beim A72 zwei Basis-ALUs plus eine weitere Multi-Taktzyklus-ALU für komplexe Rechenoperationen, gibt es nur noch zwei ALUs, die zu den Basisoperationen zusätzlich entweder multiplizieren oder dividieren können. Während also beim A72 die beiden Basis-ALUs bei Abarbeitung einer MAC-Operation frei für andere Aufgaben blieben, müssen beim A73 parallel beide ALUs ran. Diese auf den ersten Blick nachteilige Veränderung hat aber auch Vorteile: Durch die Parallelisierung wird z. B. die Sättigungsarithmetik beschleunigt. Die ALU für Multiplikation kann zudem Taktzyklen einsparen, wenn bei einer 64×64-bit-Multiplikation die jeweils oberen 32 bit der 64-bit-Operanden Null sind.