Instruction Set Architektur und Mikroarchitektur von CPUs
- Ersteller HenryWince
- Erstellt am
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
Durch einige Postings hier im Forum habe ich den Eindruck erhalten, dass es nicht schadet über diese beiden Themen etwas Grundlagenwissen beizusteuern. Vieleicht hilft dies ja einige Streitpunkte zu klären.
Instruction Set Architektur
Schon in den 60ern gab es Leute die zwischen Architektur und Implementierung unterschieden. Dazu ein Zitat aus "Architecture of the IBM System/360" (1967) von Amdahl et al:
"Computer architecture is defined as the attributes and behavior if a computer as seen from a machine language programmer. This definition includes the instruction set, instruction formats, operation codes, addressing modes, and all registers and memory locations that may be directly manipulated by the machine language programmer.
Implementation is defined as the actual hardware structure, logic design, and data path organisation of a particular embodiment of the architecture."
Bezogen auf CPUs heist das nichts anderes als, dass eine Instruction Set Architektur [ISA] das Verhalten aller denkbaren Implementierungen (=Mikroarchitekturen) definiert. Die ISA ist also derjenige Teil eines Prozessors, der für Programierer sichtbar ist. Er stellt die Schnittstelle zwischen Hardware und Software dar.
Eine ISA kann man anhand von fünf Merkmalgruppen beschreiben:
1) Operandenspeicher in der CPU (=> Wo werden Operanden in der CPU gehalten? ALU/AKKU/REGISTER)
2) Anzahl der explizit genannten Operanden (=> Wieviele Operanden einer Instruktion sind nicht statisch festgelegt?)
3) Operandenlokation (=> Wo können Operanden liegen? Nur in der CPU oder auch im Memory?)
4) Operationen (Welche Operationen werden von der ISA unterstützt, Instruktionsformate und Codierung)
5) Typ und Größe der Operanden (=> INT/FLOAT/FIXPOINT/etc, wie werden diese Spezifiziert?)
Die klassische Einteilung von ISAs kann man Anhand von (1) vornehmen:
A) Stack-Orientiert: Alle Operanden befinden sich implizit auf dem Stack
Vorteile: Kurze Instruktionen; einfache Ausdruckauswertung
Nachteile: Kein Wahlfreier Zugriff; Schwierig effizienten Code zu generieren; Stack wird zum Bottelneck weil jede Operation darauf zugreift.
B) Akku-Basiert: Ein Operand ist implizit der Akkumulator.
Vorteile: Kurze Anweisungen
Nachteile: Der Akku ist der einzige temporäre Zwischenspeicher, dadurch unnötiges ein und auslagern in den Speicher (=> Bottleneck)
C) Register-Basiert: Die Operanden werden explizit benannt, entweder duch Register oder Speicherstellen.
Vorteile: Einfache Code Generierung, Daten können über lange Zeiten im Register Verbleiben
Nachteile: Die Operanden müssen explizit benannt werden (=> längere Instruktionen)
Nicht alle Prozessoren können eindeutig einer dieser Kategorien zugeordnet werden (x86 z.B. hat viele Instruktionen die implizite Operanden besitzen). Trozdem kann sind im wesentlichen alle neuen ISAs Register-Basiert. Die Gründe dafür liegen auf der Hand: Register sind schneller als Speicher; mehr Daten können in der CPU verbleiben; es ist für Compiler einfach(er) auf Register zuzugreigen.
Es gibt noch viele weitere Einteilungsmöglichkeiten die alle die ein oder andere Facette der oben genannten Merkmale wiederspiegeln. Einige Beispiele:
Mit (2) läst sich zwischen 0-,1-,2- und 3-Adress-ISAs unterscheiden
Mit (3) kann man zwischen LOAD/STORE und MEMORY OPERATE ISAs unterscheiden
Mit (4) kann man zwischen VECTOR und SKALAR ISAs unterscheiden
Mit (5) kann man zwischen zwischen 8/16/32/64 Bit ISAs unterscheiden
Eine der häufigsten ISA-Einteilungen ist die in RISC (Reduced Instruction Set Computer) und CISC (Complex Instruction Set Computer). Hier eine Gegenüberstellung:
Quintessenz: Der einzige Nachteil von RISC ISAs ist die größere Code Size, demgegenüber haben CISC ISAs aber strukturelle Nachteile. Das einzig noch gepflegte CISC ISA ist x86, hier liegt der Grund aber nicht in den Merkmalen und Eigenschaften von CISC an sich, sondern am Interesse der Rückwärtskompatibilität!
Mikroarchitektur
Die Mikroarchitektur einer CPU bestimmt WIE die ISA implementiert wird.
Heute verwenden x86 Prozessoren Techniken, die erst mit den ersten RISC Chips in Mode kamen. Dazu zählen z.B. Pipelining, Out of order execution, Multiple Instruction Issue, etc. Deshalb wird bei modernen x86 CPUs oft auch von einer RISCartigen Mikroarchitektur gesprochen. Das hat aber nichts mit der Tatsache zu tun das das ISA nach wie vor CISC ist und bleibt! Egal wie schnell so eine CPU je sein wird, das x86 ISA limitiert letztendlich die Flexibilität der Implementierung.
Streitpunkte
Falsch, s.o.
S.o. RISC ist eine Sache des ISA und nicht der Mikroarchitektur!
S.o. ISA und Mikroarchitektur sind zwei paar Stiefel!
Angesichts der Häufigkeit von SQRT und Integer Div in normalem Code kann ich gut nachvollziehen, warum Witec & Co auf diese Befehle verzichtet haben. Deshalb wird das ganze per Sotware gelöst.
SQRT lässt sich schnell in Software Implementieren, ggf. kann man dabei sogar auf besondere Randbedingungen (wie z.B benötigte Präzision, Remainder,...) Rücksicht nehmen. Typische Algorithmen: Newton-Ralphson mit (a,b) <= ((a+y*b)/2,b*(2-a*b)) (a konvergiert gegen die Wurzel und b gegen den Rezipokwert).
Für Integer geht es noch schneller ohne MUL mit z.B. sowas:
Loop Unroling würde in diesem Beispiel einiges an Mehrperformance rauskitzeln!
Bei DIV kann man locker den Weg über FP gehen (kostet 2 zusätzliche Convert Instructions a 1 cycle).
Warum soll CISC da flexibler sein? So lange die Performance stimmt ist es doch egal wie das gelöst ist. x86 hat ja z.B. auch kein Integer sqrt() und ist deshalb noch lange nicht unflexibel.
Instruction Set Architektur
Schon in den 60ern gab es Leute die zwischen Architektur und Implementierung unterschieden. Dazu ein Zitat aus "Architecture of the IBM System/360" (1967) von Amdahl et al:
"Computer architecture is defined as the attributes and behavior if a computer as seen from a machine language programmer. This definition includes the instruction set, instruction formats, operation codes, addressing modes, and all registers and memory locations that may be directly manipulated by the machine language programmer.
Implementation is defined as the actual hardware structure, logic design, and data path organisation of a particular embodiment of the architecture."
Bezogen auf CPUs heist das nichts anderes als, dass eine Instruction Set Architektur [ISA] das Verhalten aller denkbaren Implementierungen (=Mikroarchitekturen) definiert. Die ISA ist also derjenige Teil eines Prozessors, der für Programierer sichtbar ist. Er stellt die Schnittstelle zwischen Hardware und Software dar.
Eine ISA kann man anhand von fünf Merkmalgruppen beschreiben:
1) Operandenspeicher in der CPU (=> Wo werden Operanden in der CPU gehalten? ALU/AKKU/REGISTER)
2) Anzahl der explizit genannten Operanden (=> Wieviele Operanden einer Instruktion sind nicht statisch festgelegt?)
3) Operandenlokation (=> Wo können Operanden liegen? Nur in der CPU oder auch im Memory?)
4) Operationen (Welche Operationen werden von der ISA unterstützt, Instruktionsformate und Codierung)
5) Typ und Größe der Operanden (=> INT/FLOAT/FIXPOINT/etc, wie werden diese Spezifiziert?)
Die klassische Einteilung von ISAs kann man Anhand von (1) vornehmen:
A) Stack-Orientiert: Alle Operanden befinden sich implizit auf dem Stack
Vorteile: Kurze Instruktionen; einfache Ausdruckauswertung
Nachteile: Kein Wahlfreier Zugriff; Schwierig effizienten Code zu generieren; Stack wird zum Bottelneck weil jede Operation darauf zugreift.
B) Akku-Basiert: Ein Operand ist implizit der Akkumulator.
Vorteile: Kurze Anweisungen
Nachteile: Der Akku ist der einzige temporäre Zwischenspeicher, dadurch unnötiges ein und auslagern in den Speicher (=> Bottleneck)
C) Register-Basiert: Die Operanden werden explizit benannt, entweder duch Register oder Speicherstellen.
Vorteile: Einfache Code Generierung, Daten können über lange Zeiten im Register Verbleiben
Nachteile: Die Operanden müssen explizit benannt werden (=> längere Instruktionen)
Nicht alle Prozessoren können eindeutig einer dieser Kategorien zugeordnet werden (x86 z.B. hat viele Instruktionen die implizite Operanden besitzen). Trozdem kann sind im wesentlichen alle neuen ISAs Register-Basiert. Die Gründe dafür liegen auf der Hand: Register sind schneller als Speicher; mehr Daten können in der CPU verbleiben; es ist für Compiler einfach(er) auf Register zuzugreigen.
Es gibt noch viele weitere Einteilungsmöglichkeiten die alle die ein oder andere Facette der oben genannten Merkmale wiederspiegeln. Einige Beispiele:
Mit (2) läst sich zwischen 0-,1-,2- und 3-Adress-ISAs unterscheiden
Mit (3) kann man zwischen LOAD/STORE und MEMORY OPERATE ISAs unterscheiden
Mit (4) kann man zwischen VECTOR und SKALAR ISAs unterscheiden
Mit (5) kann man zwischen zwischen 8/16/32/64 Bit ISAs unterscheiden
Eine der häufigsten ISA-Einteilungen ist die in RISC (Reduced Instruction Set Computer) und CISC (Complex Instruction Set Computer). Hier eine Gegenüberstellung:
Code:
----------------------------+------------------------+--------------------------------------------------
CISC | RISC | Design-Auswirkungen
----------------------------+------------------------+--------------------------------------------------
Variable Instruktions-Länge | Fixe Instruktionslänge | CISC: + Höhere Code-Dichte
(typisch 1-16 byte) | (meist 32 Bit pro | - Komplexer Decoder
| Instruction) | - schwierigeres prefetching und pipelining
| | RISC: + Einfacher Decoder
| | + Simple Prefetch und Pipeline Logik
| | - Längere Instruktionen
----------------------------+------------------------+--------------------------------------------------
Memory/Operate Befehle | LOAD/OPERATE/STORE | CISC: - ALU Befehle die Operanden im Memory an-
| | sprechen haben schwankende Ausfürungszeiten
| | (=> Memory Latenz) das erschwert es ein
| | optimales Scheduling zu erzeugen. Weiterhin
| | erschwert es auch die Implementation von
| | Multiple-Issue und Pipelining.
| | RISC: + Keine der o.g. Probleme
| | - Seperate Instruktionen für IO benötigen
| | mehr Speicherplatz und Bandbreite.
----------------------------+------------------------+--------------------------------------------------
Typisch: 2 Operanden | Typisch: 3 Operanden | CISC: + kürzere Instruktionen
| | - Destination Register überschieben
| | RISC: - längere Instruktionen
| | + spart Register saves
----------------------------+------------------------+--------------------------------------------------
Viele Spezial Instruktionen | Konzentration auf | CISC: + Beschleunigung einiger Operationen
| häufig benutzte | - Sehr schwer für Compiler in optimalen
| Instruktionen | Code umsetzbar
| (General Purpose) | - Komplexe Befehle benötigen entweder
| | dedizierte Hardware oder Microcode
| | - Unterschiedliche Execution Latenzen
| | RISC: + Weniger Implementierungshindernisse
| | + Etwa gleiche Execution Latenzen
| | - Performance einiger Algorithmen
----------------------------+------------------------+--------------------------------------------------
Wenige General Purpose | Viele GPR (meist 32) | CISC: + Kürzere Instruktionen
Register (<16) | | - Häufigere sicherung der Register
| | - Schwieriger für Compiler
| | RISC: + Seltener Register Resource Probleme
| | - Code Size
----------------------------+------------------------+--------------------------------------------------Mikroarchitektur
Die Mikroarchitektur einer CPU bestimmt WIE die ISA implementiert wird.
Heute verwenden x86 Prozessoren Techniken, die erst mit den ersten RISC Chips in Mode kamen. Dazu zählen z.B. Pipelining, Out of order execution, Multiple Instruction Issue, etc. Deshalb wird bei modernen x86 CPUs oft auch von einer RISCartigen Mikroarchitektur gesprochen. Das hat aber nichts mit der Tatsache zu tun das das ISA nach wie vor CISC ist und bleibt! Egal wie schnell so eine CPU je sein wird, das x86 ISA limitiert letztendlich die Flexibilität der Implementierung.
Streitpunkte
Falsch, s.o.
S.o. RISC ist eine Sache des ISA und nicht der Mikroarchitektur!
S.o. ISA und Mikroarchitektur sind zwei paar Stiefel!
Angesichts der Häufigkeit von SQRT und Integer Div in normalem Code kann ich gut nachvollziehen, warum Witec & Co auf diese Befehle verzichtet haben. Deshalb wird das ganze per Sotware gelöst.
SQRT lässt sich schnell in Software Implementieren, ggf. kann man dabei sogar auf besondere Randbedingungen (wie z.B benötigte Präzision, Remainder,...) Rücksicht nehmen. Typische Algorithmen: Newton-Ralphson mit (a,b) <= ((a+y*b)/2,b*(2-a*b)) (a konvergiert gegen die Wurzel und b gegen den Rezipokwert).
Für Integer geht es noch schneller ohne MUL mit z.B. sowas:
Code:
unsigned simple_sqrt(unsigned val)
{
unsigned temp;
unsigned guess=0;
unsigned bit = 0x8000;
unsigned shft = 15;
do
{
temp = (((guess<<1)+bit)<<shft--);
if (val >= temp)
{
guess += bit;
val -= temp;
}
} while (bit >>= 1);
return guess;
}Bei DIV kann man locker den Weg über FP gehen (kostet 2 zusätzliche Convert Instructions a 1 cycle).
Warum soll CISC da flexibler sein? So lange die Performance stimmt ist es doch egal wie das gelöst ist. x86 hat ja z.B. auch kein Integer sqrt() und ist deshalb noch lange nicht unflexibel.
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Super Thread, ich werds mir morgen (heute 
) mal durchlesen. Hast du was dagegen, wenn ich deine Tabelle dann kopiere und das ganze als Bild reinstelle? Im Moment zieht das den Monitor (komischerweise) bei kleineren Auflösungen ziemlich in die breite und macht den Rest unleserlich 
Edit: so ist das wohl praktischer:
(http://www.planet3dnow.de/news_images/cisc_risc.png)
) mal durchlesen. Hast du was dagegen, wenn ich deine Tabelle dann kopiere und das ganze als Bild reinstelle? Im Moment zieht das den Monitor (komischerweise) bei kleineren Auflösungen ziemlich in die breite und macht den Rest unleserlich Edit: so ist das wohl praktischer:
(http://www.planet3dnow.de/news_images/cisc_risc.png)
Zuletzt bearbeitet:
Hehe ...
THX HenryWince
Jeder reagiert da anders auf gewisse Threads und die Art und Weise dort etwas zu posten.
Verstehe zwar immer noch nicht alles, aber good work
Meine Antwort zu einigen Threads ist der Alphathread. Alphas allerletzte Inkarnation
Leider ist dieser RISC CISC Thread um so notwendiegr geworden, da zur Zeit die Opteronlinksammlung irgendwie beim Editieren geschreddert wurde ...
Waren ja nur so`n paar Links
@Nero24 ... Jaaaa ich weiss, betrachte dies als Vorbereitung, ich schwimme mich zur Zeit frei ...
MFG Bokill
THX HenryWince
Jeder reagiert da anders auf gewisse Threads und die Art und Weise dort etwas zu posten.
Verstehe zwar immer noch nicht alles, aber good work
Meine Antwort zu einigen Threads ist der Alphathread. Alphas allerletzte Inkarnation
Leider ist dieser RISC CISC Thread um so notwendiegr geworden, da zur Zeit die Opteronlinksammlung irgendwie beim Editieren geschreddert wurde ...
Waren ja nur so`n paar Links
@Nero24 ... Jaaaa ich weiss, betrachte dies als Vorbereitung, ich schwimme mich zur Zeit frei ...
MFG Bokill
mtb][sledgehammer
Grand Admiral Special
Habe den Text immernoch nicht ganz gelesen, ist mir einfach zu umständlich ständig links rechts zu scrollen. Habe aber drei Fragen:
1.) Habe mich mal wieder durch den Software Optimization Guide des Hämmers gequält und festgestellt, dass dieser mittlerweile DIV und SQRT als Double decodiert. Sprich es stört den Pipeline Fluss nicht. Sehe ich das richtig, dass der µOP direkt die entsprechenden Untereinheiten anspricht?
2.) Wie funktionieren die Vektor dekodierten Befehle? Werden dann entsprehchend mehr µOps dekodiert, die sequentiell auf ein und demselben Operand ausgeführt werden?
3.) Ich habe gelesen, dass beispielweise der Itanium durch die Software DIVs einen höheren Durchsatz erreicht. Eigentlich müsste man aber die Befehle auch bei x86 in Software codieren können, um den Durchsatz zu erhöhen?
1.) Habe mich mal wieder durch den Software Optimization Guide des Hämmers gequält und festgestellt, dass dieser mittlerweile DIV und SQRT als Double decodiert. Sprich es stört den Pipeline Fluss nicht. Sehe ich das richtig, dass der µOP direkt die entsprechenden Untereinheiten anspricht?
2.) Wie funktionieren die Vektor dekodierten Befehle? Werden dann entsprehchend mehr µOps dekodiert, die sequentiell auf ein und demselben Operand ausgeführt werden?
3.) Ich habe gelesen, dass beispielweise der Itanium durch die Software DIVs einen höheren Durchsatz erreicht. Eigentlich müsste man aber die Befehle auch bei x86 in Software codieren können, um den Durchsatz zu erhöhen?
Kann mir mal jemand den Sinn von meinen Quotes da oben erklären? 
Text nicht verstanden, setzen, 6!
Du kannst eine CPU in mehrere ISAs unterteilen. Mein Text bezog sich in keinster weise auf die x86 ISA, sondern auf die darunterliegende - nämlich das, was der Decoder ausspuckt.
Diese ISA, die nach dem Decoder steht ist eher RISC-Artig. Klar ist die Sache mit rein RISC oder rein CISC Wortklauberei, das hat Puck im Ausgangsthread schonmal angesprochen und da stimme ich auch vollkommen zu.
Damit der Sinn meiner eigentlichen Aussage nicht völlig verloren geht: Nach dem Decoder sieht der x86 Code bei einem K5 völlig anders aus als bei einem K6, die ROPs vom K5 sehen völlig anders aus als die ROPs (oder wie immer die beim K6 heißen mögen) beim K6 oder die µOps beim P6.
Die bilden jeweils eine eigenständige ISA, der Decoder übersetzt von x86 CISC in die jeweilige ISA, also K5 ROPs, K6
, P6 µOps usw.
NOPE!
Überall wo du halbwegs standarisierte Befehle hast kannst du von einer ISA sprechen. Klar gibt es dafür jeweils nur eine Implementierung (nämlich die jeweilige CPU), aber trotzdem kannst du das als ISA bezeichnen.
Du kannst auch den AT Modem Standard als ISA bezeichnen.
Jetzt wird mir allmählich klar, wieso der 128bit CPU Thread nicht vom Fleck gekommen ist - ist ja logisch, wenn meine Aussagen falsch interpretiert werden
.
Ach ja -
Woher nimmst du die Aussage, dass CISC strukturelle Nachteile hat? Das ist deine MEINUNG. Genauso die Sache mit den wenigen GPRs, AMD64 hat zb. schon deutlich mehr und es könnten problemlos noch mehr werden (aber irgendwo verliert sich da dann der Sinn).
Wenn das deine MEINUNG ist hab ich damit kein Problem. Wenn du das als allgemeine Weisheit darstellst schon... (denn genau das ist es definitiv nicht)
Text nicht verstanden, setzen, 6!
Du kannst eine CPU in mehrere ISAs unterteilen. Mein Text bezog sich in keinster weise auf die x86 ISA, sondern auf die darunterliegende - nämlich das, was der Decoder ausspuckt.
Diese ISA, die nach dem Decoder steht ist eher RISC-Artig. Klar ist die Sache mit rein RISC oder rein CISC Wortklauberei, das hat Puck im Ausgangsthread schonmal angesprochen und da stimme ich auch vollkommen zu.
Damit der Sinn meiner eigentlichen Aussage nicht völlig verloren geht: Nach dem Decoder sieht der x86 Code bei einem K5 völlig anders aus als bei einem K6, die ROPs vom K5 sehen völlig anders aus als die ROPs (oder wie immer die beim K6 heißen mögen) beim K6 oder die µOps beim P6.
Die bilden jeweils eine eigenständige ISA, der Decoder übersetzt von x86 CISC in die jeweilige ISA, also K5 ROPs, K6
, P6 µOps usw. NOPE!
Überall wo du halbwegs standarisierte Befehle hast kannst du von einer ISA sprechen. Klar gibt es dafür jeweils nur eine Implementierung (nämlich die jeweilige CPU), aber trotzdem kannst du das als ISA bezeichnen.
Du kannst auch den AT Modem Standard als ISA bezeichnen.
Jetzt wird mir allmählich klar, wieso der 128bit CPU Thread nicht vom Fleck gekommen ist - ist ja logisch, wenn meine Aussagen falsch interpretiert werden
.Ach ja -
Woher nimmst du die Aussage, dass CISC strukturelle Nachteile hat? Das ist deine MEINUNG. Genauso die Sache mit den wenigen GPRs, AMD64 hat zb. schon deutlich mehr und es könnten problemlos noch mehr werden (aber irgendwo verliert sich da dann der Sinn).
Wenn das deine MEINUNG ist hab ich damit kein Problem. Wenn du das als allgemeine Weisheit darstellst schon... (denn genau das ist es definitiv nicht)
Da wird mir jetzt so einiges klar.
Das ist doch der Hauptvorteil von CISC, du kannst es übersetzen in was du willst. Ob das nun die ISA vom K5 ist (ROPs, steht übrigens für Risc OPeration, soviel zum RISC Desing), die völlig andere ISA vom K6, die wieder völlig andere ISA vom K7 oder eben die in ihrer Entwicklungsdauer ziemlich unveränderte ISA vom P6 - alles möglich.
Dagegen kannst du RISC nur mit viel Aufwand in eine andere RISC ISA übersetzen. Und die RISC ISAs vom zb. K7 ist sehr leistungsfähig, und wenig GPRs gibts da auch nicht (man beachte zb. die 88 FPU Register, dazu noch haufenweise Integer GPRs).
Das sind alles ISAs die state of the art waren, die jeweils einfach das modernste waren (bzw. sind) was möglich ist.
Und das trotz Abwärtskompatiblität dank des Decoders, der die x86 ISA auf die jeweils CPU speziefische ISA übersetzt. Die Transmeta sind das extremste Beispiel.
Also versuch doch einfach mal meine Aussagen so zu interpretieren, dass sie einen Sinn ergeben - ich werd ja wohl kaum offensichtlich sinnfreies Zeug daherbrabbeln.
Und ich muss mich nochmal über die CISC/RISC Gegenüberstellung aufregen, die ist nämlich allenfalls unvollständig und ziemlich sinnfrei (da nicht allgemein CISC/RISC sondern x86 / RISC verglichen wird).
Das ist doch der Hauptvorteil von CISC, du kannst es übersetzen in was du willst. Ob das nun die ISA vom K5 ist (ROPs, steht übrigens für Risc OPeration, soviel zum RISC Desing), die völlig andere ISA vom K6, die wieder völlig andere ISA vom K7 oder eben die in ihrer Entwicklungsdauer ziemlich unveränderte ISA vom P6 - alles möglich.
Dagegen kannst du RISC nur mit viel Aufwand in eine andere RISC ISA übersetzen. Und die RISC ISAs vom zb. K7 ist sehr leistungsfähig, und wenig GPRs gibts da auch nicht (man beachte zb. die 88 FPU Register, dazu noch haufenweise Integer GPRs).
Das sind alles ISAs die state of the art waren, die jeweils einfach das modernste waren (bzw. sind
) was möglich ist. Und das trotz Abwärtskompatiblität dank des Decoders, der die x86 ISA auf die jeweils CPU speziefische ISA übersetzt. Die Transmeta sind das extremste Beispiel.
Also versuch doch einfach mal meine Aussagen so zu interpretieren, dass sie einen Sinn ergeben - ich werd ja wohl kaum offensichtlich sinnfreies Zeug daherbrabbeln
.Und ich muss mich nochmal über die CISC/RISC Gegenüberstellung aufregen, die ist nämlich allenfalls unvollständig und ziemlich sinnfrei (da nicht allgemein CISC/RISC sondern x86 / RISC verglichen wird).
@intel_hasser
Dein Enthusiasmus in allen Ehren ...
aber HenryWince zitiert da eine Definition von jemanden, der nicht unbedeutend ist ... einen gewissen Amdal.
Wie Gordon Moore (Moore`s Gestz) hat dieser Amdal das Denken der IT-Industrie geformt und geprägt "Amdals`s Gesetz"
Ich für meinen Teil habe ISA immer nach der Definition von Amdal et Co genutzt. Damals war es ja ein elementarer Schritt, dass nicht Rechnertypisch immer wieder eine eigene Sprache erfunden wurde, sondern eine allgemeinere universelle Sprache geschaffen wurde.
Eigentlich ist der PC auch nach dieser Ideologie geschaffen worden. x86 ist da ganz besonders extrem, da hier intel & IBM die Kompatibelität herausstellten.
IBM versuchte alte Zöpfe mit dem Microchannel abzuschneiden, und ging grandios dabei unter, dennoch wurde immer vom "PC" als IBM kompatiblen gesprochen ... ehrlicherweise müsste dies intelkompatibel heissen.
Erstmals erfolgreich; AMD64
Insofern ist die Leistung von AMD um so bemerkenswerter, da sie es geschafft haben mit AMD64 erstmals vor dem Marktführer erfolgreich einen eigenen Standard zu definieren. Basierend auf IA32.
3DNOW! war zwar auch eigenständig und baute auf intel`s Standard MMX auf ... erfolgreich waren sie aber nicht, jedenfalls übernahm intel 3DNOW! nicht, sondern entwickelte eine konkurrierende SIMD-Einheit.
MFG Bokill
Dein Enthusiasmus in allen Ehren ...
aber HenryWince zitiert da eine Definition von jemanden, der nicht unbedeutend ist ... einen gewissen Amdal.
Wie Gordon Moore (Moore`s Gestz) hat dieser Amdal das Denken der IT-Industrie geformt und geprägt "Amdals`s Gesetz"
Ich für meinen Teil habe ISA immer nach der Definition von Amdal et Co genutzt. Damals war es ja ein elementarer Schritt, dass nicht Rechnertypisch immer wieder eine eigene Sprache erfunden wurde, sondern eine allgemeinere universelle Sprache geschaffen wurde.
Eigentlich ist der PC auch nach dieser Ideologie geschaffen worden. x86 ist da ganz besonders extrem, da hier intel & IBM die Kompatibelität herausstellten.
IBM versuchte alte Zöpfe mit dem Microchannel abzuschneiden, und ging grandios dabei unter, dennoch wurde immer vom "PC" als IBM kompatiblen gesprochen ... ehrlicherweise müsste dies intelkompatibel heissen.
Erstmals erfolgreich; AMD64
Insofern ist die Leistung von AMD um so bemerkenswerter, da sie es geschafft haben mit AMD64 erstmals vor dem Marktführer erfolgreich einen eigenen Standard zu definieren. Basierend auf IA32.
3DNOW! war zwar auch eigenständig und baute auf intel`s Standard MMX auf ... erfolgreich waren sie aber nicht, jedenfalls übernahm intel 3DNOW! nicht, sondern entwickelte eine konkurrierende SIMD-Einheit.
MFG Bokill
Mag ja sein, der Vergleich CISC vs. RISC ist trotzdem allenfalls unvollständig, und dieses Thema kann man auch nicht in einer so kleinen Tabelle abhandeln - das muss einfach schief gehen.
Ein LEA auf x86 ist zb. schneller erledigt als die selbe Implementierung auf RISC (bzw. der Aufwand ist bei RISC höher, da zb. mehr Befehle dekodiert werden müssen).
Taucht irgendwas dieses Thema betreffend im Vergleich auf? Nein...
Warum eigentlich setzen sich langsam Graka-ISAs durch? Ist doch völlig sinnlos, und die Befehle sind auch eher CISC-artig.
Trotzdem zerrechnet eine akutelle Graka jede CPU, ob RISC ob CISC ob VLIW ob EPIC...
Und die Graka Shadersprachen nehmen immer mehr die Form von CPU ISAs an, das ganze wird immer dynamischer.
Gegen die Definition ISA sag ich ja auch garnix, darunter kann man aber trotzdem so ziemlich alles verstehen. Eine Programmiersprache (also eine HLL) könnte man auch als ISA bezeichnen, sie erfüllt alle Vorraussetzungen. Damit sind wir beim nächsten Punkt - vokale Sprachen...
Also du siehst, das Spiel kann man endlos weitertreiben. Irgendwo kann man alles als ISA bezeichnen (was aber nicht negativ ist).
Und der original PC kam von IBM - das ist schon richtig, MCA kam aber erst später (und ging noch später unter).
Von der Sache her ist es falsch zu sagen, irgendwas brauche einen IBM kompatiblen PC - das wäre dann ein 8086 und den braucht man heute ziemlich selten. Richtiger wäre ein Intel i386/IA32 kompatibler PC. Das könnte aber trotzdem auch ein Rechner mit MCA sein, solange eben alles so implementiert ist, dass es PC kompatibel ist (die Bussysteme haben damit eher wenig zutun).
PuckPoltergeist
Grand Admiral Special
Nein, geht nicht. Das solltest du schon daran sehen, was für ein Aufwand nötig ist, x86 in die entsprechenden makro-OPs (oder was auch immer) zu zerlegen, mal ganz davon abgesehen, dass es gar nicht vollständig möglich ist.
Weiß ich nicht, aber ich denke nicht, dass es so schwierig ist. Die meisten RISC-ISAs ähneln sich sehr stark.
Also versuch doch einfach mal meine Aussagen so zu interpretieren, dass sie einen Sinn ergeben - ich werd ja wohl kaum offensichtlich sinnfreies Zeug daherbrabbeln
Aber auch du kannst dich irren.
Wo gibt es denn für dich Anlass zur Kritik?
mtb][sledgehammer
Grand Admiral Special
Was soll eigentlich dieses: "Bei CISC ist der Dekoderaufwand enorm"?
Schaut mal folgendes Bild an
http://www.chip-architect.net/news/Opteron_Instr_Cache.jpg
Ich würde sagen der Dekoder macht wenn es hoch kommt heute noch 5 % aus (an Chipfläche). Das ganze nimmt beim K8 AFAIK zwar 3 Takte in Anspruch, doch wieviel besser sieht die Sache bei RISC aus, beispielsweise dem G5? Der verarbeitet ja die RISC Ops auch nicht direkt sondern dekodiert sie in IOPs? Das ist genauso 1 oder mehr Taktstufen.
Dagegen hat man soweit ich das verstanden habe nun bei CISC den Vorteil, dass ein dekodierter Befehl deutlich mehr Inhalt hat. bei RISC muss also noch ein Befehl dekodiert werden, um das selbe Ergebnis wie ein CiSC Befehl liefern zu können.
BTW: Kann auch jemand meine Fragen oben beantwaorten?
Schaut mal folgendes Bild an
http://www.chip-architect.net/news/Opteron_Instr_Cache.jpg
Ich würde sagen der Dekoder macht wenn es hoch kommt heute noch 5 % aus (an Chipfläche). Das ganze nimmt beim K8 AFAIK zwar 3 Takte in Anspruch, doch wieviel besser sieht die Sache bei RISC aus, beispielsweise dem G5? Der verarbeitet ja die RISC Ops auch nicht direkt sondern dekodiert sie in IOPs? Das ist genauso 1 oder mehr Taktstufen.
Dagegen hat man soweit ich das verstanden habe nun bei CISC den Vorteil, dass ein dekodierter Befehl deutlich mehr Inhalt hat. bei RISC muss also noch ein Befehl dekodiert werden, um das selbe Ergebnis wie ein CiSC Befehl liefern zu können.
BTW: Kann auch jemand meine Fragen oben beantwaorten?
Ohne Dokus zu wälzen oder mein Hirn auf extreme Anforderungen zu stellen kann ich dir jetzt leider nur die 3. Frage beantworten - der Itanium hat verschiedene möglichkeiten DIV auszuführen, einmal auf Durchsatz und einmal auf Latenz optimiert.
Theoretisch müsste sich das auch bei x86 realisieren lassen, allerdings wird der Itanium bei den verschiedenen Divs sicherlich auch einige FPU Sachen anders benutzen. Käme auf den Versuch an, auf jeden Fall kann man aktuellen Compilern auch sagen, dass sie komplexe FPU Operationen in Software durchführen sollen (beim gcc zb. -fno-fancymath oder so).
Bei der Dekodersache kann ich mich nur anschließen, heutige Dekoder klingen zwar ziemlich komplex vom Aufbau her, sind aber nix gegen die anderen Einheiten die es so noch in der CPU gibt.
Und die Übersetzung von CISC in RISC ist einfach leichter als von RISC in RISC, wenn die RISC ISAs nicht wirklich größerenteils identisch sind.
Bei x86 ist damit ja noch ein Geschwindigkeitsvorteil verbunden (CISC ist kleiner und kompakter als RISC), bei RISC zu RISC gibts diesen Geschwindigkeitsvorteil nicht.
Theoretisch müsste sich das auch bei x86 realisieren lassen, allerdings wird der Itanium bei den verschiedenen Divs sicherlich auch einige FPU Sachen anders benutzen. Käme auf den Versuch an, auf jeden Fall kann man aktuellen Compilern auch sagen, dass sie komplexe FPU Operationen in Software durchführen sollen (beim gcc zb. -fno-fancymath oder so).
Bei der Dekodersache kann ich mich nur anschließen, heutige Dekoder klingen zwar ziemlich komplex vom Aufbau her, sind aber nix gegen die anderen Einheiten die es so noch in der CPU gibt.
Und die Übersetzung von CISC in RISC ist einfach leichter als von RISC in RISC, wenn die RISC ISAs nicht wirklich größerenteils identisch sind.
Bei x86 ist damit ja noch ein Geschwindigkeitsvorteil verbunden (CISC ist kleiner und kompakter als RISC), bei RISC zu RISC gibts diesen Geschwindigkeitsvorteil nicht.
@mtb][sledgehammer
Gutes Bild!
Was sagte jemand im 3DCenter ... "Die Decodier/Encodierfrage bei x86 ist gelöst"
Mit deiner Aussage mit den 5% ist`s nur etwas anders formuliert
Zum Vectorpfad
Auch wenn der Thread Alphas allerletzte Inkarnation etwas anders gestrickt ist.
Ein x86 CISC-RISC Decoder muss hier schon Klimmzüge machen, damit dies erreicht wird. (Ist eigentlich wirklich bekannt wie breit die internen Datenworte in diesen Decodereinheiten von CISC zu RISC sind? )
Der Vectorpfad scheint mir auch kein Problem zu sein. Weswegen? Nun AMD selber sagte bei dem Übergang vom Palomino zum Thoroughbred, dass die SSE Eingeit verbessert wurde.
Vieles was der Palomino vorher durch den Vectorpfad machte, soll der Thoroughbred direkt implantiert bekommen haben.
Der K8 hat in dieser Hinsicht noch weitere Verbesserungen bekommen haben.
Der Vektorpfad ist meiner Meinung nach nur eine Beschreibung, dass eben viele RISC OPS in einer festgelegten Reihenfolge genommen werden müssen, um einen noch nicht "fix" verdrahteten Befehl nachzubilden.
Es ist gleichsam ein Kochrezept für längere Instruktionsfolgen.
So gesehen stört die Betrachtung gar nicht, dass die Eleganz von RISC durchbrochen wird. Es hat den Anschein, dass aus Kostengrümden so Transistoren eingespart werden können mit dem Preis der Geschwindigkeit.
MFG Bokill
Gutes Bild!
Was sagte jemand im 3DCenter ... "Die Decodier/Encodierfrage bei x86 ist gelöst"
Mit deiner Aussage mit den 5% ist`s nur etwas anders formuliert
Zum Vectorpfad
Auch wenn der Thread Alphas allerletzte Inkarnation etwas anders gestrickt ist.
Codelänge und Codegrösse alleine ist nicht zwingend schlecht. Der Lohn für die Gleichförmigkeit ist der wesentlich vereinfachte Verwaltungsaufwand und der vermutlich bessere gleichmässige Datendurchsatz.
Ein x86 CISC-RISC Decoder muss hier schon Klimmzüge machen, damit dies erreicht wird. (Ist eigentlich wirklich bekannt wie breit die internen Datenworte in diesen Decodereinheiten von CISC zu RISC sind? )
Der Vectorpfad scheint mir auch kein Problem zu sein. Weswegen? Nun AMD selber sagte bei dem Übergang vom Palomino zum Thoroughbred, dass die SSE Eingeit verbessert wurde.
Vieles was der Palomino vorher durch den Vectorpfad machte, soll der Thoroughbred direkt implantiert bekommen haben.
Der K8 hat in dieser Hinsicht noch weitere Verbesserungen bekommen haben.
Der Vektorpfad ist meiner Meinung nach nur eine Beschreibung, dass eben viele RISC OPS in einer festgelegten Reihenfolge genommen werden müssen, um einen noch nicht "fix" verdrahteten Befehl nachzubilden.
Es ist gleichsam ein Kochrezept für längere Instruktionsfolgen.
So gesehen stört die Betrachtung gar nicht, dass die Eleganz von RISC durchbrochen wird. Es hat den Anschein, dass aus Kostengrümden so Transistoren eingespart werden können mit dem Preis der Geschwindigkeit.
MFG Bokill
PuckPoltergeist
Grand Admiral Special
Ja, aber der Vector Path ist ja auch wieder K7/K8 speziefisch. Der K5 hat den zb. nicht.
Und die Sache mit dem Microcode Prog... naja, man müsste überhaupt erstmal entscheiden, was RISC und was CISC bedeutet. Ich glaube allerdings nicht, dass der Microcode da erstmal alles andere stoppt und dann exklusiv die einzelne Anweisung ausführt.
Das tritt aber sowieso nur sehr selten auf, und ein ordentlicher Compiler umgeht Vector Path Instructions wenn diese langsamer sind... sind diese schneller ist das ein weiterer Sieg für CISC (müssen ja nicht alle langsamer sein als die Ops, die den normalen Weg gehen).
Und die Sache mit dem Microcode Prog... naja, man müsste überhaupt erstmal entscheiden, was RISC und was CISC bedeutet. Ich glaube allerdings nicht, dass der Microcode da erstmal alles andere stoppt und dann exklusiv die einzelne Anweisung ausführt.
Das tritt aber sowieso nur sehr selten auf, und ein ordentlicher Compiler umgeht Vector Path Instructions wenn diese langsamer sind... sind diese schneller ist das ein weiterer Sieg für CISC
(müssen ja nicht alle langsamer sein als die Ops, die den normalen Weg gehen).
PuckPoltergeist
Grand Admiral Special
'türlich, vielleicht unter anderem Namen, die Technik ist aber gleich.
Die Definition steht oben. Ist die jenige welche, die du kritisiert hast.
Wie war das nochmal mit dem Aussageninterpretieren? x86 ist CISC, das ist klar. Andererseits hat x86 auch nix mit der Implementierung zu tun, von daher kann die CPU selbst was anderes sein.
Der Decoder spuckt RISC aus, oder sagen wir ziemlich viel RISC. Die Frage ist wo man das Microcodeprog einordnet.
PS Und wenn du dir so sicher bist, dass der K5 auch Anweisungen per Microcode ausführt kannst du mir ja sicherlich auch die Quelle nennen.
Es wäre nicht verwunderlich, mich k**** es aber langsam an, dass du einfach so pauschal Aussagen in den Raum stellst. Du weist garnicht ob der K5 sowas auch hat!
PuckPoltergeist
Grand Admiral Special
CISC, weil dies ein Teil der Definition ist.
Kannst du die Quelle
nennen, dass der K5 alle Anweisungen in RISC-artige Instruktionen übersetzt? Ich gebe ehrlich zu, ich mutmaße hier nur. Der Ausgangspunkt dafür ist die Tatsache, dass weder K8 noch K7 oder K6 dies können. Wenn es der K5 konnte, wieso hat AMD dann diesen Rückschritt gemacht? Wenn ich mich richtig erinner, wurde die Übersetzung mit jeder CPU-Generation verbessert, sprich es konnten mehr Befehle zerlegt werden. Was macht dich so sicher, dass der K5 dort das Nonplus-Ultra ist/war?BTW, kennt jemand eine Seite, wo aufgeschlüsselt steht, in welche/wieviele makro-OPs die AMD-CPUs die entsprechenden x86-Befehle zerlegen? Eins-zu-eins dürfte ja nicht möglich sein, sonst könnte man sich gleich das Übersetzen sparen.
Original geschrieben von PuckPoltergeist
CISC, weil dies ein Teil der Definition ist.
Kannst du die Quelle
BTW, kennt jemand eine Seite, wo aufgeschlüsselt steht, in welche/wieviele makro-OPs die AMD-CPUs die entsprechenden x86-Befehle zerlegen? Eins-zu-eins dürfte ja nicht möglich sein, sonst könnte man sich gleich das Übersetzen sparen.
Das mit dem K5 war um dich endlich mal darauf zu stoßen. Und (das kann ich mir jetzt einfach net verkneifen
) - wüsstest du die Geschichte der AMD CPUs, dann wüsstest du auch, dass AMD bisher nur beim Schritt K7 -> K8 ein altes Desing fortgeführt hat.Der K5 war die erste AMD CPU die x86 in RISC artige Befehle (ROPs) übersetzt hat. Der war allerdings zu komplex, und man hat lange auf der Stelle getreten.
Also wurde der Nexgen 686er dazugekauft, woraus der K6 wurde. Der K6 ist also garnicht von AMD entwickelt, sondern von Nexgen.
Der K7 war dann wieder eine völlige Neutentwicklung, eben wieder ein AMD Desing.
Sowas aufeinander aufbauendes wie bei Intel, wo man den PPro immer etwas weiter verbessert hat, gab es bei AMD bisher nicht. Der K7 stellt mit seinen Untervarianten da den Anfang dar, und der K8 führt das fort.
Ich geb zu ich weis es auch nicht (wie gesagt...) - aber der K5 hat definitiv keinen Vector Path, und mehr hab ich auch garnicht gesagt,
Möglich, dass der K5 auch nicht alle CISC Anweisungen durchgehend in RISC überträgt, aber ich hab bisher auc nicht gelesen, dass er das nicht tut. Auf jeden Fall wäre aber pauschal die Variante vom K5 nicht mit der von K7 vergleichbar, weil man sowas auch völlig anders implementieren könnte.
So, schluss damit... wir schweifen vom Thema ab
.Der Definition wovon? Von x86? Von K7 RISC-artigen Befehlssatz? Imho laufen zuwenig Befehle durch den Vector-Path, um das eindeutig sagen zu können. Imho...
PS Die Cruseo und Efficeon übersetzen übrigens alles in VLIW
PuckPoltergeist
Grand Admiral Special
Definition von CISC, die ja oben steht. Deine Frage war, wo das Microcode-Programm einzuordnen ist, und das ist definitiv CISC.
Ich sehe keinen Wiedersprcuh zu meiner bisherigen Aussage.
Der Prozessor K87 hat zwei Arten CISC x86 Instruktionen intern zu wandeln.
1. direct path instruction
2. vector path instruction
am Ende der Wandlung beider Pfade steht der interne µOPS oder ROPS oder was auch immer. Jedenfalls ist intern die eigentliche Rechenarbeit RISC.
Jetzt kommt der Witz
Die Instruktion selber ist aber immer noch CISC x86. Die Umwandlungsarbeit steht ja noch bevor.
Quelle der Zitate http://www.chip-architect.net/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html#4.3
MFG Bokill
Der Prozessor K87 hat zwei Arten CISC x86 Instruktionen intern zu wandeln.
1. direct path instruction
2. vector path instruction
am Ende der Wandlung beider Pfade steht der interne µOPS oder ROPS oder was auch immer. Jedenfalls ist intern die eigentliche Rechenarbeit RISC.
Hier scheint es sich um eine Vorsortierfunktion zu handeln. CISC hat ja unterschiedlich lange Bitlängen.
Jetzt kommt der Witz
Ist Funktionsbit am Ende "0", so darf der CISC-RISC Prädecoder diese CISC Instruktion direkt in den RISC Decoder einspeisen. Der "direct" Pfad. Offensichtlich scheint hier eine mundgerechte Instruktionslänge vorzuliegen.
Die Instruktion selber ist aber immer noch CISC x86. Die Umwandlungsarbeit steht ja noch bevor.
Ist Funktionsbit am Ende "1", so muss der CISC-RISC Prädecoder eine Extrarunde einlegen. Der Vector Pfad.
Was doch nichts anderes bedeutet, dass dieser CISC Befehl vorverdaut werden muss in ein Prä-RISC Decodertaugliches Format. Übersetzen dauert nun mal länger als, das direkte Einlesen von Befehlen. Es ist gleichsam zerlegter "entbeinter" CISC Code.
Quelle der Zitate http://www.chip-architect.net/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html#4.3
MFG Bokill
PuckPoltergeist
Grand Admiral Special
Nein, soweit ich weiß, wird da nix mehr übersetzt. Bis zum 486 wurde das ja auch nicht gemacht, sondern jeder Befehl via Mikroprogrammwerk abgearbeitet. Nichts wesentlich anderes dürfte der Vector Path sein.
Tja, also entweder bedeutete Vector Path eine Extrarunde für den Decoder, der daraus auch nur RISC(-ariges) macht, oder wirklich CISC.
Imho wäre ersteres logischer, da man sonst einen riesigen Aufwand für Pipelining, OOO, RegRenaming usw. hätte, damit das konsistent bleibt.
Bin jetzt aber zu faul mir das durchzulesen und rauszusuchen
.
Imho wäre ersteres logischer, da man sonst einen riesigen Aufwand für Pipelining, OOO, RegRenaming usw. hätte, damit das konsistent bleibt.
Bin jetzt aber zu faul mir das durchzulesen und rauszusuchen
.
PuckPoltergeist
Grand Admiral Special
Original geschrieben von intel_hasser
Imho wäre ersteres logischer, da man sonst einen riesigen Aufwand für Pipelining, OOO, RegRenaming usw. hätte, damit das konsistent bleibt.
Bin jetzt aber zu faul mir das durchzulesen und rauszusuchen
Ich bin mir aber ziemlich sicher, dass es letzteres ist (hatte da mal einen Artikel, den ich jetzt garantiert nicht wieder finde
). Auch per direct path lassen sich die Befehle ja nicht direkt in makro-OPs zerlegen, sondern mehrere makro-OPs sind für einen x86-Befehl notwendig. Außerdem bräuchte man ja kein Mikroprogrammwerk, wenn man die Befehle vollständig zerlegen könnte.Stimmt auch wieder. Vielleicht gibts aber auch einige x86 Ops, die sich nicht nach Schema F in ROPs zerlegen lassen. Andererseits fallen mir da nicht wirklich welche ein, was aber ohne genaue Kentniss der K7 ISA (also dem RISC(-artigen) Teil) auch nicht verwunderlich ist.
Morgen such ich vielleicht mal danach...
Morgen such ich vielleicht mal danach...
Ähnliche Themen
