VLIW Sprungvorhersage

Wüsste auch gerne warum das bei VLIW unmöglich sein sollte. Und EPIC 
versucht zwar, die Anzahl von Sprüngen durch predication zu reduzieren, 
aber ganz ohne geht's da auch nicht.

Sicher gibt's ein paar neue Hürden. So können VLIWs möglicherweise 
mehrere Sprünge pro Befehl enthalten. Aber das ist nicht wirklich ein 
Hindernis, denn das fügt der Vorhersage lediglich eine Ebene hinzu 
("welcher isses denn?").

Ich könnte mir vorstellen, dass eine dynamische Sprungvorhersage extrem 
kompliziert ist - eben genau wegen dem VLIW.
Schon bei aktuellen x86er ist die Sprungvorhersage eine der 
kompliziertesten Geschichten in der CPU.

3349 wrote:

> VLIW hat mehrere Spruenge per Zeile ? Eher nicht. Wie soll denn das
> gehen ?

Warum sollte das bei bedingten Sprüngen nicht gehen? Es kann nur nicht 
mehr als einer davon tatsächlich ausgeführt werden. Stell dir mal die 
Realisierung eines switch-Statements vor, wenn eine Tabelle keinen Sinn 
ergibt.

I_ H. wrote:

> Ich könnte mir vorstellen, dass eine dynamische Sprungvorhersage extrem
> kompliziert ist - eben genau wegen dem VLIW.

Sehe ich nicht. AMDs Architekturen erinnern seit K7/Athlon bereits etwas 
an VLIW. Die branch prediction arbeitet in 16 (K7-K8) bis 32 (K10) Byte 
breiten fetch blocks, wobei mit Einschränkungen mehrere darin enthaltene 
branches parallel gehandhabt werden (wenn maximal einer davon dynamisch 
ist). Danach werden (interne) Befehle in Zeilen aus 3 Stück bis zum 
retirement parallel durchgeschoben.

Das ist natürlich noch nicht das Ende, eben die dynamische Vorhersage 
von mehreren gleichzeitig fehlt noch. Und AMDs predictor ist dafür nicht 
unbedingt ideal, aufgrund der Abhängigkeit verschiedener branches 
untereinander. Aber local predictors (vgl. P3) geht das problemlos.

Branch prediction wird auch deshalb immer komplexer, weil Fehler darin 
meist keine dramatischen Auswirkungen haben und die Designer sich 
folglich fast ad infinitum austoben können. Immerhin arbeiten die 
Verfahren meist fail-safe, weil weiter hintern ja ohnehin alles nochmal 
kontrolliert wird. Einzig eine target instruction prediction ist 
kritisch - prompt war AMD beim branch target line cache des ersten K6 da 
auch reingetappt.

Naja, so'n VLIW und auch EPIC Design ist aber was ganz anderes als eine 
aktuelle x86 CPU.
K10 und P3 sind auf massives out-of-order ausgelegt, weil sonst nix bei 
rauskommt. Da wird "wild" mit irgendwelchen Sprungvorhersagealgorithmen 
rumspekuliert, der Befehlssatz vollständig umcodiert, das Zeugs auf 
Shadowregister verteilt usw.

Dementsprechend steckt in x86 CPUs extrem viel Entwicklungsaufwand. Die 
Dinger sind bei "üblichen" Sachen zwar effizienter als die ganzen 
anderen Desings (Power, Itanium usw.), aber auch 10mal so kompliziert.
Heute stampft niemand mal eben einen guten x86er aus dem Boden, allein 
die Tatsache das alle heutigen Designs ziemlich alte Vorfahren haben 
zeigt denke ich, wie schwer sowas ist (K10 -> nicht unähnlich K6, und K6 
lief früher mal als NexGen 686; Core Duo -> P3 -> PPro; Via wieauchimmer 
-> IDT Winchip).

Der einzige Herteller der sich mit VLIW bei x86 probiert hat war 
Transmeta. Die CPU war - wie für VLIW typisch - ziemlich einfach 
aufgebaut und hatte trotzdem brachiale Rechenleistung. Der Großteil ging 
allerdings für's Codemorphing drauf.

Also man könnte sicher eine VLIW Architektur mit dynamischer 
Sprungvorhersage bauen, aber einmal wird die dann noch komplizierter, 
und zum anderen entspricht das auch garnicht der VLIW-Philosophie. Die 
Dinger sind nicht für Spiele oder Desktop gedacht, sondern für 
numerische Berechnungen.
Die "Dynamik" bei der Befehlsausführung wie x86er (irgend'n Code in dem 
alle 3 Behfehle ein bedinger Sprung drinnen ist, und die CPU führt's so 
aus als wär kein einziger Sprung drinnen) erreicht VLIW schon 
prinzipbedingt nicht.
EPIC auch nicht. Man muss sich mal vor Augen halten, das ein aktueller 
Opteron mit ca. 100Mio Transistoren in ähnlichen Bereichen wie ein 
Itanium mit x-mal so vielen Ausführungseinheiten und 2Mrd Transistoren 
liegt. Außer man lässt den Itanium das machen was er wirklich kann.



Muss aber dazusagen, dass ich bei dem Thema inzwischen etwas raus bin. 
Daher sowenig handfeste Details.