Herdware schrieb:
Intel hatte sich damals, bei Schritt auf 64Bit entschieden, auf eine ganz neue, modernere RISC-Archtektur zu wechseln (Itanium).
Nein, Itanium ist kein RISC, sondern ein erweitertes VILW-Design, dass in seiner Form sehr stark vom Compiler abhängt, da diesem weite Teile der Out-of-Order-Sortierung zu gefallen wäre und dieser beim Compilieren die OPs entsprechend gekennzeichnet hätte, so dass der Itanium aus den kommenden OPs passende MarkoOPs hätte bauen können um alle ALUs auszulasten.
Herdware schrieb:
AMD entschied sich bei erweitertem x86 und CISC zu bleiben, was aber, wenn ich die Aussage von Anand und Weber nicht ganz missverstehe, halt doch nur den Decoder betrifft und der Rest der CPU davon unabhängig ist.
Das Problem ist viel eher, dass du an der Stelle versucht verschiedene Sachen von einander zu trennen, die man so nicht trennen kann, weil es sich Gegenseitig beinflusst, deswegen auch mein Hinweis, dass es ja nicht nur an CISC - damit den Decoder - alleine liegt, sondern ebenso auch an den Spezifikationen, die mit der ISA getroffen werden.
Herdware schrieb:
... doch auch die x86-CPUs schon längst (seit dem Pentium Pro und AMD K6?) "RISC". Da unterscheiden sich AMD64, x86, IA64 und ARM letztlich nicht oder nur sehr wenig.
Ja und Nein zu gleich unglaublich komplex.
Richtig ist, dass RISC-Ansätze mit der Zeit in die x86 "Hardware"-Architektur eingeflossen sind. Bereits der i486 hat die CISC-Marko-Befehle in kleine MikroOPs zerlegt, damit man diese besser auf die ALUs und LD/St aufteilen kann. Das waren dann die ersten Pipeline-Ansätze, die mit dem P5 ausgebaut wurden.
Der P6 war dann MikroOPs, die RISC ähnlich sind, da zu dann super Skalarität, OoO und Co. Man hat dann wegen der Pipeline, wegen OoO und weil man mehr ALUs pro Kern unter bringen wollte, entsprechend auf RISC-Interne verarbeitung umgesattelt.
Und damit kommen wir zu einem weiteren Punkt: Bei den frühen Pentium Pros sowie K6, K7 und auch K8, sprechen wir von CPUs, die Anfangs eine zweite "ALU" einführten, die Decoder damals konnten 2 Befehle pro Takt in die MikroOPs zerlegen um die Pipeline zu füllen. Mit OoO versuchte man dann die beide ALUs parallel rechenn zu lassen.
Heute - bereits recht lange - hängen die Decoder von Intel und AMD bei 4 Befehlen fest und man versucht sogar alles mögliche um möglichst viele Befehle in einem MikroOP-Cache zu halten, weil das Decodierine sehr aufwendig ist. Man nutzt hier also bereits einen Zwischenspeicher und die Tatsache, dass es Schleifen und Co in Programmen gibt, nur damit man um das Decodieren herum kommt, weil das eben Zeit braucht.
RISC-Befehle sind bereits in der Regel "atomar", während man bei CISC durchaus ein paar späße haben konnte, die in RISC nicht gehen. Da kommen wir halt dazu, dass früher die Register in CISC feste "Aufgaben" hatten. Klar, wird heute durch "Register"-Umbenennung umgangen und die Verallgemeinerung der Register in x86_64 hilft da, aber doch merkt man auch da das alters.
Das ist jetzt nur ein "Fiktives" Beispiel - ich hab ewig nicht mehr Assembler programmiert auf nem CISC, 15 Jahre nicht mehr, aber wir hatten durchaus da sowas:
ADD_SAV 54, 43, 0x01. Das haben wir so in den ROM eingeben als Assembler: Addiere 54 + 43 und speicher das im RAM an Stelle 0x01.
Der Decode macht daraus dann das und so kommen aber auch bereits die RISC-Befehle an.
Code:
LD r1 54
LD r2 43
ADD r1, r2
SAV r1, 0x01
Dazu die Sache mit den Registern. Die Anzahl macht hier auch viel aus und warum der M1 "effizienter" ist, denn mit 31 Registern kann er wesentlich länger auf LOAD und STORE-Anweisungen verzichten in der Pipeline, weil alles in den Registern liegt und die Compiler wissen das auch. Wie ich sagte: Bereits in den 80er wusste man, das LOAD, STORE und COPY die Effizienz eines Prozessores einbrechen lässt, weil man auf Daten wartet.
Klar, heute mit Register-Renaming und Co, kann man da einiges optimieren nur ... solche Späße haben ja moderne ARM-Kerne auch und wieder: 31 Register schlagen 16.
Es ist irrelevant, ob heute x86-Kerne intern "RISCfy" sind und ARM-CPUs intern genau so wie x86-CPUs arbeiten. Die Probleme liegen in der ISA und mit welchem Hintergedanken die ISA in den 70er entworfen wurde und das hat bis heute Auswirkung, auch wenn AMD mit x64 einige dieser Probleme angegangen ist.
