Befehlssatzerweiterungen einer CPU

[mehmet_b_90]

Hallo zusammen,

ich weiß jetzt nicht ob dieses Thema hier reinpasst?! Leider habe ich über Google und hier im Forum nichts darüber gefunden.
Auf jedenfall möchte ich gerne wissen wie man eine Befehlssatzerweiterung einer CPU sich vorstellen kann - z.B. die SSE, AES usw.

Die x86-Architektur von Intel wurde von damals mit einem Satz von Befehlen entworfen, die bis jetzt immer mit Erweiterungen bestückt wurde, um die CPU schneller und effizienter zu gestallten. Wie kann man sich eine Befehlssatzerweiterung vorstellen? Zum Beispiel die AES-Erweiterung? Sind es schon vorgeschriebene Methoden, wie in Programmiersprachen, die schon in der CPU direkt integriert sind?

Danke im voraus.

MfG
Mehmet1990

 

[bambule1986]

Hat Google keine passende Antwort ausgespuckt?

 

[miac]

Die Erweiterungen bestehen aus Assemblerbefehlen und zusätzlicher Hardware auf der CPU.
Die Assemblerbefehle werden vom Microcode in der CPU entsprechend auf die Hardware angewendet. Sind die Erweiterungen der CPU nicht verfügbar, müssen sie emuliert werden.

 

[Arcturus]

Die Compiler müssen die Zusätzlichen Befehle unterstützen und die Programme auch entsprechend kompiliert werden.
Dann brauchst du beispielsweise halt nur einen Befehl, wos vorher zwei waren, und sparst Rechenzeit.
Normalerweise wird das über Flags im Compiler aktiviert.

 

[Yuuri]

Ganz einfach ausgedrückt: "Befehle" werden in Hardware gegossen, wodurch eine Operation weniger Taktzyklen benötigt bzw. eben auch mehr Daten gleichzeitig verarbeitet werden können. Das multipliziert mit der Menge an Befehlen, ergibt eine kürzere Abarbeitungszeit.

Statt also bspw. eine Multiplikation mit anschließender Division in zwei Operationen aufzuteilen (mit jeweils Daten holen + speichern), würde also bspw. ein muldiv mit Angabe dreier Zahlen reichen und du erhälst die Division zweier multiplizierter Zahlen in einem Takt.

Genauso müssen aber auch 64 bit lange Zahlen (long int) oder Fließkommawerte nicht mehr in zwei Takten und 32 bit Breite abgearbeitet werden bzw. heutzutage können eben 128 bit lange Zahlen (2x 64 bit) in einem Rutsch abgearbeitet werden.

 

[Toms]

Naja, intern (also die Recheneinheiten ansich) rechnen x86-CPUs bereits seit meines Wissens dem Pentium M mit einem proprietären RISC-Befehlssatz (RISC = Reduced Instruction Set Computer). x86-Befehle sind aber CISC-(Complex Instruction Set Computer)Befehle. Um die x86-Befehle in die nativen Befehle umzuwandeln braucht es Decoder, die vor jeden Kern (Intel) bzw. vor jedes Modul (AMD) geschnallt werden. Diese "übersetzen" die komplexen x86-CISC-Befehle in die RISC-Befehle für die Recheneinheit um. Die Befehlssätze umgehen meines Wissens jetzt die Decoder und werden nativ von den Recheneinheiten verstanden, sodass die Zeit die durch das Übersetzen wegfällt erstmal eingespart wird. Zusätzlich trifft das ein, was Yuuri bereits vor mir erwähnt hatte.

 

[mehmet_b_90]

Danke für die schnellen Antworten.

 

[Samurai76]

Nein, der X86 ist immer noch ein CISC Prozesser. Dieses 'Übersetzen' wie du es nennst, ist von einer Hochsprache (Basic, Pascal, C++ etc) in Assembler, da das Programmieren in Assembler keinen Spass macht. Und obwohl es den Anschein macht, verglichen mit einer Hochsprache, dass Assembler einen reduzierten Befehlssatz hat, ist das noch eine komplexe Sprache (CISC). Und die Assembler Befehle werden von der CPU sogar noch weiter zerlegt, in den soganannten Mikrocode. Das macht aber die CPU.

 

[Toms]

Ja er kann CISC Befehle verstehen, ist intern jedoch ein RISC (seit Pentium M)

Quelle Wikipedia:
https://de.wikipedia.org/wiki/Reduced_Instruction_Set_Computer#Vergleich_zu_CISC

"der Intel x86-Linie verdrängt, die einen RISC-Kern mit einer CISC-Emulationsschicht verbinden"


Das in Assembler "Übersetzen" übernimmt bereits der Compiler Der kompiliert es in Assembler und der Assemblierer wandelt den Code nochmals um

 

[Samurai76]

Ok, lassen wir X86 CPU's ab dem Pentium M als halb/halb durchgehen. Da aber im Betrieb (wenn OS geladen ist), kein Microcode direkt zur Ausführung gebracht werden kann, sondern der Prozessor nur mit Assembler Befehlen zum Arbeiten bewegt wird, sehe ich diese Prozessoren trotzdem als CISC an. Da aber ALLE Prozessoren nur mit NOR/NAND/NOT/XOR Gattern arbeiten (und damit eigentlich nur addieren können), könnte man sonst alle Prozessoren als RISC bezeichnen, zumindest haben sie alle einen RISC Kern. Aber das schweift vom Thema ab.

 

[Toms]

Alles klar

 

[Nai]

Weil ich das etwas interessant finde, etwas ausführlicheres dazu von mir, sogar wenn es evtl etwas Off-Topic ist.

Woraus besteht eine Befehlssatzerweiterung? Eine Befehlssatzerweiterung erweitert die Hardware des Prozessors (in den meisten Fällen) um Folgendes:
-Zusätzliche Kontrollogik zum dekodieren und Scheduling der entsprechenden Befehle.
-Zusätzliche Register, also schneller on-DIE-Speicher in dem die Operanden für die Befehle abgespeichert werden.
-Entsprechende Modifikationen an den Ausführungseinheiten oder zusätzliche Ausführungseinheiten für die neuen Befehle.

Wie versucht man durch Befehlssatzerweiterung die Performance zu erhöhen? Dahinter stecken zwei etwas leicht unterschiedliche Grundideen, wobei eine Befehlssatzerweiterung sich auch eine Kombination von beiden zu Nutze machen kann:

-Man fasst mehrere einfache eventuell verschiedene Befehle angewendet auf Daten, die voneinander abhängig sind, zu einem komplexeren und spezielleren Befehl zusammen (Spezialisierung). Unter diese Kathegorie fällt zum Beispiel das sehr bekannte Fused-Multiply-Add:
Ergebnis := A+B*C
Durch das Zusammenfassen sorgt man nun dafür, dass die Kontrolllogik entlastet wird, weil sie den Befehl nur einmal herausgeben muss, und die Register entlastet werden, da die Daten nur einmal zwischen Registern und Ausführungseinheiten transferiert werden müssen. Die Ausführungseinheiten werden ebenfalls entlastet, indem man sie komplexer und spezieller macht, so dass sie den komplexeren Befehl in weniger Takten als die Teilbefehle einzeln ausführen können. Alternativ kann man auch zusätzliche spezielle Ausführungseinheiten einfügen, die nur die neuen Befehle ausführen können, so dass die anderen Ausführungseinheiten ebenfalls entlastet werden. Durch dieses Zusammenfassen kann man die Performance der CPU bei dem Ausführen eines bestimmten Befehls erhöhen. Allerdings kostet diese Spezialisierung auch Chipfläche, welche einem nur etwas bringt, wenn die neuen Befehle auch Verwendung finden. Diejenigen Prozessorbefehle, welche bei aktuellen Befehlssatzerweiterungen dazukommen und in diese Kathegorie fallen, sind meistens sehr spezielle Instruktionen, welche man beispielhaft nur bei Video En- oder Dekodierung oder bei der En- oder Decryption benötigt. Interessanterweise haben GPUs ebenfalls sehr spezielle Befehle, welche in diese Kathegorie fallen, wie zum Beispiel für das Samplen (= interpolierender Zugriff) von Texturen.

Anmerkung am Rande: Man benötigt nur wenige Bit-Befehle der ALU um alles mögliche berechnen zu können, wodurch alle übrigen Befehle eines Prozessors prinzipiell in diese Kathegorie fallen. Demnach kann man auch sämtliche FPU-Befehle per ALU berechnen, welche dafür allerdings wesentlich mehr Takte benötigen würde.


-Man fasst mehrmals den selben Befehl ausgeführt auf voneinander unabhängigen Daten zu einem Befehl zusammen (Parallelisierung per SIMD-Instruktionen, Single Instruction Multiple Data). Hierunter fällt zum Beispiel die Vektoraddition:
Ergebnisvektor := VektorA + VektorB
Bei den SIMD-Instruktionen benötigt man wiederum weniger Kontrolllogik, da der Befehl nur einmal herausgegeben werden muss, allerdings benötigt man breitere Register für die Operanden des Befehls (in dem obigen Beispiel wären es Register für VektorA und VektorB) und breitere beziehungsweise zusätzliche Ausführungseinheiten um dafür zu sorgen, dass die entsprechenden Daten auch parallel abgearbeitet werden können. Eine weitere Grund dafür, dass man SIMD-Instruktionen implementiert ist, dass man die Kontrolllogik und die Ausführungseinheiten eines Prozessorkerns nicht beliebig schnell machen kann. Bei dieser Begrenzung ist man mittlerweile langsam angekommen. Will man nun die (Single-Threaded-)Leistung eines Prozessorkerns weiter erhöhen, so kann man ihn nur mit SIMD-Instruktionen ausstatten beziehungsweise die vorhandenen SIMD-Instruktionen breiter (mehr Daten pro Instruktion gleichzeitig) machen, und weitere zusätzliche beziehungsweise breitere Ausführungseinheiten einbauen. Dies äußert sich auch bei der Prozessorentwicklung: Bei Core2 und Nehalem waren die SIMD-SP-Instruktion noch 4 breit, während sie bei Haswell/Sandy/Ivy schon 8 breit sind. Um die SIMD-Instruktionen zu nutzen muss bei einem Algorithmus allerdings eine gewisse Parallelität auf Befehlsebene vorhanden sein, welche der Compiler in SIMD-Instruktionen umwandeln kann; schafft er das nicht, so bringen die SIMD-Befehle keinen Performancevorteil.

Anmerkung am Rande: Die höhere Rohleistung von GPUs im Vergleich zu Prozessoren liegt unter anderem darinnen begründet, dass sie wesentliche breitere SIMD-Instruktionen als Prozessoren verwenden (64 und 32 bei GPUs vs. 8 und 4 bei Prozessoren) und sich dann dementsprechend Kontrollogik einsparen

 

[Kantonspital]

Weil ich das etwas interessant finde, etwas ausführlicheres dazu von mir, sogar wenn es evtl etwas Off-Topic ist.

Woraus besteht eine Befehlssatzerweiterung? Eine Befehlssatzerweiterung erweitert die Hardware des Prozessors (in den meisten Fällen) um Folgendes:
-Zusätzliche Kontrollogik zum dekodieren und Scheduling der entsprechenden Befehle.
-Zusätzliche Register, also schneller on-DIE-Speicher in dem die Operanden für die Befehle abgespeichert werden.
-Entsprechende Modifikationen an den Ausführungseinheiten oder zusätzliche Ausführungseinheiten für die neuen Befehle.

....

Hallo Nai,
(deine Antwort ist schon bisschen her)

Worum ich Dich bitte, da du den Sachverhalt besser verstehst als ich:
Macht es nicht Sinn, bei aktuellen CPU Entwicklungen (Stand 10/2023: 5nm/
solche Befehlserweiterungen komplett aus der CPU zu entfernen ?

Weil:
1) Diese ganzen Erweiterungen (MMX, SSE, SSE2, SSE3, SSSE3, SSE4a, SSE4.1, SSE4.2, CLMUL, AES, AVX, AVX2, AMD64, NX-Bit, SMP, OPM und AMD-V) brauchen doch nur Platz auf dem Die.
2) Mit anderen CPU Konzepten (biglittle, extra AI Kerne) sind die alten Erweiterungen doch obsolet.
Wie bei ARM. Da werden aktuelle CPUs doch auch nach Armv9-A und nicht nach ARMv5TE entwickelt.
3) Welches Programm nutzt wirklich Erweiterungen wie MMX, SSE welche aus 1993 kommen ?
Wahrscheinlich keine. Warum behält man sie dann bei ?

Danke

 

[Nai]

1) Diese ganzen Erweiterungen (MMX, SSE, SSE2, SSE3, SSSE3, SSE4a, SSE4.1, SSE4.2, CLMUL, AES, AVX, AVX2, AMD64, NX-Bit, SMP, OPM und AMD-V) brauchen doch nur Platz auf dem Die.

Hier sind viele unterschiedliche Arten von Befehlssatzerweiterungen genannt worden, die alle unterschiedliche (nützliche) Zwecke erfüllen: Virtualisierungserweiterungen (AMD-V), Sicherheitserweiterungen (NX-Bit) und Vektorerweiterungen (MMX, SSE, SSE2, SSE3, SSSE3, SSE4a, SSE4.1, SSE4.2, AVX, AVX2), Erweiterung der arithmetischen Instruktionen (AES, CLMUL), Speichererweiterungen (AMD64, was nebenbei auch eine arithmetische Erweiterung ist) und zwei Funktionalitäten, wo ich unsicher bin, ob dies überhaupt durch Befehlssatzerweiterungen realisiert wird (OPM und SMP). Mein 10 Jahre alter Post war auf Vektorerweiterungen und Erweiterungen der arithmetischen Operationen bezogen.

Bei den ganzen Vektorerweiterungen gilt, dass eine neue Vektorerweiterung in der Regel eine Erweiterung der vorherigen Vektorerweiterung ist, d.h. die neue Vektorerweiterung stellt im Vergleich zur vorherigen Vektorerweiterung noch neue Vektorinstruktionen, breitere Vektorinstruktionen und breitere Vektorregister zur Verfügung. (Beispiel: AVX erweitert SSE4, AVX2 erweitert AVX und AVX512 erweitert AVX2). Dadurch kann das Steuerwerk der CPU all diese Vektorerweiterungen über die gleichen Rechenwerke und den gleichen Registersatz abwickeln, wodurch für das Mitschleifen von alten Vektorerweiterungen keinerlei Chipfläche verschwendet wird.

Mit anderen CPU Konzepten (biglittle, extra AI Kerne) sind die alten Erweiterungen doch obsolet.

Wieso sollten sie? Über (breitere) Vektorinstruktionen z.B. kann der Anteil an Rechenwerken auf dem DIE erhöht und der Anteil an Kontrolleinheiten reduziert werden, wodurch sich auch der Rechendurchsatz des Chips, sofern diese Vektorinstruktionen auch verwendet werden, deutlich erhöht.

Da werden aktuelle CPUs doch auch nach Armv9-A und nicht nach ARMv5TE entwickelt.

Damit bewirkt ARM nur, dass diverse Funktionalitäten Standard werden, und nicht mehr über Befehlssatzerweiterungen optional sind, wodurch wiederum die Entwicklung von Software und Compilern vereinfacht wird. Ebenso sind ARM-CPUs abwärtskompatibel, d.h. der Code für ältere ARM CPUs läuft auch auf aktuellen ARM CPUs. Chipfläche spart sich ARM dadurch keine.

3) Welches Programm nutzt wirklich Erweiterungen wie MMX, SSE welche aus 1993 kommen ?
Wahrscheinlich keine. Warum behält man sie dann bei ?

Kompatibilitätsgründe, und weil es nicht viel kostet, diese zu integrieren (siehe oben). Auch werden die skalaren SSE Operationen noch für skalare Gleitkommaoperationen verwendet; zum Beispiel die einfache Programmzeile float a = float b* float c; kompiliert zu "mulss xmm0, xmm0" was eine SSE Instruktion ist.