Die Decoder an sich lassen sich genauso gut verkleinern wie auch normale Rechenwerke. Aber genau wie diese werden sie immer mächtiger – Netburst hatte [nachguck] scheinbar nur eine einzige Decoder-Pipeline und sich sonst auf seinen Micro-Op-Cache verlassen, um vier Ausführungseinheiten auszulasten (sportlich, sportlich). Bei Alder Lake sind es selbst für jeden E-Kern zwei Decoder mit drei Pipelines, zusätzlich zum Cache. Außerdem werden Decodereinheiten an sich um so komplexer, je größer der Befehlssatz wird – von SSE2 bis AVX2 ist eine ganze Menge hinzugekommen. Eine relativ zu den Ausführungseinheiten konstante Größe ist also plausibel. Was passiert, wenn man Decoderressourcen relativ zum Rechenwerk einsparen möchte, haben ja Bulldozer und Piledriver mit einem Decoder je Modul bewiesen – erst als es mit Steamroller einen Decoder pro Int-Kern gab, konnten AMDs APUs im angestrebten Low-End-Segment austeilen.
Out of Order an sich ist unabhängig von der Architektur. Alle x86-Intel-Prozessoren bis einschließlich der Sockel-7-Pentiums waren in Order und danach noch einmal die erste Atom-Architektur sowie darauf aufbauend Xeon Phi. Ich schätze mal, die für die IME verwendeten Kerne im PCH sind es bis heute (aber die sind praktisch nicht dokumentiert). Bei AMD müsste es bis einschließlich K5 gewesen sein, über Geode und die anderen Mitbewerber fehlt mir aber gerade der Überblick. Umgekehrt sind alle leistungsfähigeren ARM-Kerne OoO. Aber: Der Aufwand, der für effektiven OoO-Betrieb nötig ist, hängt von der Komplexität des Chipsatzes ab.
Bei RISC sieht die Spungvorhersage direkt im Programmcode, was als nächstes kommen könnte und jede RISC-Berechnung liefert ein Endergebnis. Bei CISC-to-RISC muss man im Front-End die Decoding-Verzögerung einplanen und entsprechend weiter vorausgucken; die Sortierung im Back-End muss Zwischenergebnisse zurück an den Anfang leiten und prüfen, ob bis zu einem CISC-Retirement noch andere RISC-Micro-Ops abgewartet werden müssen. Das alles braucht auch mehr Zeit, womit das Zeitfenster von einem CISC-Befehl bis zum nächsten, der darauf aufbauen darf, noch größer wird. Um Leerlauf zu vermeiden muss eine OoO-CISC-to-RISC-CPU also mehr Rechenaufgaben insgesamt im Blick behalten als ein reine OoO-RISC-Design. Ich weiß, wie gesagt, nicht, wie viele Transistoren das genau kostet. Aber in aller Regel gilt in der Halbleitertechnik: Klingt es kompliziert? Dann ist die Implementierung kompliziert².
Umgekehrt gibt diese Komplexität den CPU-Entwicklern aber auch Ansatzpunkte für Verbesserungen. Wenn Front- und Backend den Ansprüchen gerecht werden, können sie den Berechnungsablauf optimal für die vorhandenen Pipelines koordinieren. Bei RISC dagegen wird das dem Compiler oder gar dem Entwickler überlassen. Optimieren die sauber, wäre das Programm genauso flüssig wie beim perfekten CISC-to-RISC ablaufen – aber noch nicht zwingend schneller, denn der Programmcode ist Kern-ferner gespeichert als Microcode. Ich schätze mal, dass die langsameren Zugriffe darauf mit ein Grund sind, warum x86 bei schlecht parallelisierbaren Code bis heute ungeschlagen bleibt, obwohl Sprungvorhersage & Co bei AMD und Intel natürlich auch nicht perfekt arbeiten und händisch optimierter ARM-Code somit einen Vorteil in der Programm-Logik haben kann. Die Regel dürfte aber mit hoher Wahrscheinlichkeit das Gegenteil sein: Niemand programmiert so nah am Silizium, die Möglichkeiten eines offline arbeitenden Compilers gegenüber einer just-in-time-Sprungvorhersage haben auch nicht unendlich viel Potenzial und umgekehrt kennt niemand AMD- und Intel-Kerne so gut, wie AMD- respektive Intel-Entwickler. So passen die dekodierten Micro-Ops in einer x86-CPU dann doch wieder besser zu den Recheneinheiten, als bei einem nativen ARM-Kern, wo der Entwickler eigentlich alles direkt unter Kontrolle hat.
Und ja Du hast recht. 2 weitere Sätze meinerseits hätten das auch vermeiden können.
