Ein Lückenfüller mit Ambitionen - AMDs Brazos-Plattform im Test

Prozessoren | HT4U.net | Seite 8

Die Kerne: Die Bobcat-Architektur


Nachdem wir uns nun einen Überblick über die Brazos-Plattform verschafft haben, ist es an der Zeit sich mit den interessanten Details zu beschäftigen. Beginnen wollen wir dabei mit der Architektur der Prozessorkerne, die AMD auf den Namen "Bobcat" getauft hat. Wie bereits erwähnt handelt es sich dabei um eine Neuentwicklung, die eine akzeptable Rechenleistung bei gleichzeitig sehr geringem Energieverbrauch und niedrigen Anschaffungskosten ermöglichen soll.

Anders als Intel bei seiner Atom-Architektur wählt AMD bei Bobcat dennoch ein Out-of-Order-Design. Bei diesem können die Befehle unabhängig von der Programmreihenfolge ausgeführt werden, was gegenüber einem In-Order-Design eine deutlich höhere Performance verspricht. Muss beispielsweise Befehl A noch auf Daten aus dem Speicher warten, bevor dessen Ausführung starten kann, muss bei dem In-Order-Design des Atom auch der nachfolgende Befehl B warten, selbst wenn dieser schon bereit für die Ausführung ist. Bei einer Out-of-Order-Architektur kann der Befehl B hingegen zu erst ausgeführt werden. Dadurch wird die Wartezeit von Befehl A effizient ausgenutzt, wodurch die Performance verbessert wird. Daher setzen nahezu alle modernen Prozessoren auf ein Out-of-Order-Design. Nach der Ausführung der Befehle im Out-of-Order-Design müssen diese natürlich wieder in die ursprüngliche Programmreihenfolge gebracht werden um falschen Ergebnissen zu vermeiden.

Bild: Ein Lückenfüller mit Ambitionen – AMDs Brazos-Plattform im Test

Doch wer nun denkt, dass AMD schlicht die aktuelle Deneb-Architektur herangezogen hat und diese radikal zusammengestrichen hat, der irrt sich. In den nächsten Abschnitten wollen wir daher einen kurzen Überblick über die wichtigsten Aspekte der neuen Bobcat-Architektur geben. Zunächst werden wir dabei das Frontend der Pipeline untersuchen.


Das Frontend


Unter dem Frontend einer Prozessor-Architektur fasst man die Befehlsholstufe (Instruction Fetch) samt Sprungvorhersage (Branch Prediction) und die Decode-Stufe zusammen.

Insbesondere die Sprungvorhersage ist dabei bei der Bobcat-Architektur besonders wichtig, denn ein falsch vorhergesagter Sprung führt dazu, dass bereits berechnete Ergebnisse verworfen werden müssen, was sich in Sachen Energieverbrauch natürlich alles andere als positiv bemerkbar macht. Aus diesem Grund hat AMD die Sprungvorhersage auf den neusten Stand gebracht, wobei man hier keine genauen Details verraten will.

Bild: Ein Lückenfüller mit Ambitionen – AMDs Brazos-Plattform im Test

Die Sprungvorhersage kann maximal zwei Sprünge pro Taktzyklus vorhersagen und merkt sich dabei die Speicheradresse, in welcher sich der Sprungbefehl befindet. So kann der Prozessor schneller den Befehl erneut laden, sollte der Sprung falsch vorhergesagt worden sein. In diesem Fall entsteht durch das Verwerfen und Neuberechnen der Ergebnisse eine Verzögerung von 13 Taktzyklen.

Ein weiterer interessanter Aspekt im Frontend ist die Größe des Translation Lookaside Buffers für Instruktionen (ITLB). In einem TLB wird der Zusammenhang zwischen physikalischen Adressen und logischen Adressen wie sie von Programmen genutzt werden gespeichert. Da die Übersetzung einer logischen in eine physikalische Adresse sehr zeitaufwändig ist, ist ein großer TLB von Vorteil. Mit 512 Einträgen ist der ITLB der Bobcat-Architektur dabei erstaunlich groß. Möglicherweise kann auf diese Weise die "Memory Management Unit", die für die Adresseübersetzung zuständig ist, häufiger abgeschaltet werden, was wiederum dem Energieverbrauch zu Gute käme.

Bild: Ein Lückenfüller mit Ambitionen – AMDs Brazos-Plattform im Test

Die Befehlsholstufe kann pro Takt 32 Byte pro Zyklus aus dem 32 KByte großen L1-Instruktionscache holen und diese an die Decode-Unit weiterreichen. Diese kann anschließend bis zu zwei x86-Befehle pro Taktzyklus verarbeiten. AMD gibt dabei an, dass die Dekodier-Stufe 89 Prozent aller x86-Befehle dank eines uCode-ROMs direkt in einen einzigen maschinenverständlichen mircoOp-Befehl (uOp) übersetzen kann. Wie groß die Instruktionspuffer nach der Befehlsholstufe (Fetch Queue) bzw. der Dekodierstufe (Instuction Queue) sind, verrät AMD allerdings nicht. Gleiches gilt für die Kapazität des Reorder Buffers (ROB), der am Ende dazu dient, die ursprüngliche Befehlsreihenfolge wiederherzustellen.