Holger B. schrieb am 16. Februar 2004 10:42
> TavorJunkie schrieb am 13. Februar 2004 19:51
>
> > Voneinander abhängige
> > Instruktionen können nicht parallel Decodiert werden und eine
> > abhängige Instruktion in einem "Decode-Bundle" verlegt das Decoding
> > in den nächsten Taktzyklus!
richtig! Allerdings muss die decode-Stufe auch die rename-register
zuweisen, es muessen also die Abhaengigkeiten erkannt werden. Damit
bestehen beim 32-bit fixed-length Befehlssatz die Aufgaben aus
'dekodieren' (also ueberhaupt erst mal die Instruktionen finden) und
'renaming' der Register. Das ist immer noch einfacher als beim x86
mit variabler Befehlslaenge (hier setzt dann aber Intels Tracecache
an, man muss nicht erst nach dem Opcode gucken, die Laenge
herausfinden, den naechsten Opcode angucken usw.). Hier hat der PPC
gegenueber x86 eindeutig einen Vorteil und kann in einer kuerzeren
Pipeline mehr Befehle verarbeiten.
>
> Da bringst Du was durcheinander. Der Dekoder schert sich noch gar
> nicht darum, ob Befehle voneinander abhaengig sind, denn Operanden
> werden erst spaeter in der "Issue" Pipelinestufe gelesen.
aber das renaming geschieht schon vorher, das ist dann evtl. der
Flaschenhals.
>
> Vielleicht hast Du was ueber die Opcodes gelesen, die "millicoded"
> werden (die also in mehr als zwei "simple" Befehle uebersetzt
> werden); so eine Millicodesequenz kriegt jedesmal ihre eigene Gruppe.
> Aber dabei ist es egal, welche Abhaengigkeiten es so gibt.
Millicode wird fuer Instruktionen verwendet die zu komplex fuer die
HW sind (typischerweise seltener benoetigte Opcodes). Ausserdem
werden, z.B. bei Bugs in der CPU, Instruktionen schon auch mal auf
Millicode 'umgebogen' (wenn's denn nicht zuviel Performance kostet).
Das erspart einen Redesign und damit unmassen an Geld und Zeit.
Tolles Beispiel ist hier die IBM /390 (oder heutzutage zSeries), bei
der fast alle wichtigen Befehle 'RISC'-like sind (1-zyklisch), aber
die wahren Haemmer in der Architektur (z.B. execute, compare and
swap, ...) sind in Millicode implementiert.
>
> Oder vielleicht hatte der Text was mit einem sogenannten "LSU-Reject"
> zu tun. Dabei gehts tatsaechlich um Abhaengigkeiten innerhalb einer
> Dekodiergruppe, aber das betrifft nur "Store Forwarding" (also das
> Weiterreichen von Daten die in den Speicher geschrieben werden, und
> kurz danach von dort wieder gelesen werden, noch bevor sie physisch
> den Cache erreicht haben). Das hat allerdings nicht wirklich was mit
> dem Dekoder zu tun.
Dafuer gibt's store-buffer, und zwar in jeder halbwegs normalen
Architektur. Fuer die CPU ist der store gelaufen, die Daten haengen
noch im Buffer, ein erneutes zugreifen holt die Daten halt dann aus
diesem Buffer. Die koennen dann auch uebrigens Byte/Word/DWord-Merge.
Das ist eigentlich kein Problem, kostet halt ne Handvoll
Transistoren...
>
> Ich hab jedenfalls schon oefter Lesezugriffe und den "Verwerter" (der
> Befehl welcher mit den gelesenen Daten weiterrechnet) direkt
> hintereinander in die gleiche Gruppe gepackt. Bei G4 und frueher war
> das 'ne Performancesuende, aber beim G5 kann man auf die Art
> sichtbare Register einsparen und stattdessen Renameregister benutzen.
> Das gibt einem mehr Luft, fuer die langen Pipelines des G5 zu
> schedulen. Die Entkopplung der Lesezugriffe von den Verwertern kann
> man der "Out of Order Execution" ueberlassen.
klar, dafuer hat man die Buffer und die rename-Register. Und wenn das
ganze in HW implementiert ist dann hat man die Probleme des Merced
(aka Itanium) eben nicht. Die Programme laufen auch ohne optimalen
Compiler anstaendig und performant. Und der P4 krankt am eigentlich
pfiffigen, aber deutlich zu kleinen Trace-Cache.
>
> Holger B.
- BL
> TavorJunkie schrieb am 13. Februar 2004 19:51
>
> > Voneinander abhängige
> > Instruktionen können nicht parallel Decodiert werden und eine
> > abhängige Instruktion in einem "Decode-Bundle" verlegt das Decoding
> > in den nächsten Taktzyklus!
richtig! Allerdings muss die decode-Stufe auch die rename-register
zuweisen, es muessen also die Abhaengigkeiten erkannt werden. Damit
bestehen beim 32-bit fixed-length Befehlssatz die Aufgaben aus
'dekodieren' (also ueberhaupt erst mal die Instruktionen finden) und
'renaming' der Register. Das ist immer noch einfacher als beim x86
mit variabler Befehlslaenge (hier setzt dann aber Intels Tracecache
an, man muss nicht erst nach dem Opcode gucken, die Laenge
herausfinden, den naechsten Opcode angucken usw.). Hier hat der PPC
gegenueber x86 eindeutig einen Vorteil und kann in einer kuerzeren
Pipeline mehr Befehle verarbeiten.
>
> Da bringst Du was durcheinander. Der Dekoder schert sich noch gar
> nicht darum, ob Befehle voneinander abhaengig sind, denn Operanden
> werden erst spaeter in der "Issue" Pipelinestufe gelesen.
aber das renaming geschieht schon vorher, das ist dann evtl. der
Flaschenhals.
>
> Vielleicht hast Du was ueber die Opcodes gelesen, die "millicoded"
> werden (die also in mehr als zwei "simple" Befehle uebersetzt
> werden); so eine Millicodesequenz kriegt jedesmal ihre eigene Gruppe.
> Aber dabei ist es egal, welche Abhaengigkeiten es so gibt.
Millicode wird fuer Instruktionen verwendet die zu komplex fuer die
HW sind (typischerweise seltener benoetigte Opcodes). Ausserdem
werden, z.B. bei Bugs in der CPU, Instruktionen schon auch mal auf
Millicode 'umgebogen' (wenn's denn nicht zuviel Performance kostet).
Das erspart einen Redesign und damit unmassen an Geld und Zeit.
Tolles Beispiel ist hier die IBM /390 (oder heutzutage zSeries), bei
der fast alle wichtigen Befehle 'RISC'-like sind (1-zyklisch), aber
die wahren Haemmer in der Architektur (z.B. execute, compare and
swap, ...) sind in Millicode implementiert.
>
> Oder vielleicht hatte der Text was mit einem sogenannten "LSU-Reject"
> zu tun. Dabei gehts tatsaechlich um Abhaengigkeiten innerhalb einer
> Dekodiergruppe, aber das betrifft nur "Store Forwarding" (also das
> Weiterreichen von Daten die in den Speicher geschrieben werden, und
> kurz danach von dort wieder gelesen werden, noch bevor sie physisch
> den Cache erreicht haben). Das hat allerdings nicht wirklich was mit
> dem Dekoder zu tun.
Dafuer gibt's store-buffer, und zwar in jeder halbwegs normalen
Architektur. Fuer die CPU ist der store gelaufen, die Daten haengen
noch im Buffer, ein erneutes zugreifen holt die Daten halt dann aus
diesem Buffer. Die koennen dann auch uebrigens Byte/Word/DWord-Merge.
Das ist eigentlich kein Problem, kostet halt ne Handvoll
Transistoren...
>
> Ich hab jedenfalls schon oefter Lesezugriffe und den "Verwerter" (der
> Befehl welcher mit den gelesenen Daten weiterrechnet) direkt
> hintereinander in die gleiche Gruppe gepackt. Bei G4 und frueher war
> das 'ne Performancesuende, aber beim G5 kann man auf die Art
> sichtbare Register einsparen und stattdessen Renameregister benutzen.
> Das gibt einem mehr Luft, fuer die langen Pipelines des G5 zu
> schedulen. Die Entkopplung der Lesezugriffe von den Verwertern kann
> man der "Out of Order Execution" ueberlassen.
klar, dafuer hat man die Buffer und die rename-Register. Und wenn das
ganze in HW implementiert ist dann hat man die Probleme des Merced
(aka Itanium) eben nicht. Die Programme laufen auch ohne optimalen
Compiler anstaendig und performant. Und der P4 krankt am eigentlich
pfiffigen, aber deutlich zu kleinen Trace-Cache.
>
> Holger B.
- BL