www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik VLIW Sprungvorhersage


Autor: blupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi.

Ich hab ein Buch, in welchen behauptet wird dass dynamische 
Sprungvorhersage bei VLIW unmöglich und bei EPIC Architekturen schwer 
möglich ist.
Ich sehe irgendwie keinen Grund dafür, kann das jemand erläutern?

Nach allem was ich jetzt gelesen habe, schien es mir so zu sein, dass es 
einfach eine Designentscheidung ist, man will soviel wie möglich den 
Compiler übernehmen lassen.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?").

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wen es noch interessiert:
Da ich mit VLIW und EPIC nun rein garnichts anfangen konnte, hab' ich 
mal gegoogelt
u.a.:

http://www.tecchannel.de/server/hardware/402288/index5.html

seite 5 von 17, geht also noch weiter.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 3349 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VLIW hat mehrere Spruenge per Zeile ? Eher nicht. Wie soll denn das 
gehen ?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Intel hat die lange Pipeline mit der Netburst Architektur beim P4 als 
Irrweg eingestuft. Es geht wieder mit PIII bzw Pentium M Technologie 
weiter.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.