VLIW
VLIW steht für very long Instruction Word und ist eine Computerarchitektur. Zuerst einmal was ist damit gemeint? Gemeint sind nicht lange Befehlsworte, die es auch gibt. Bei der x86 Architektur können sie z.B. bis zu 16 Bytes lang sein. So lange Befehlsorte bekommt man z.B. bei SIMD Architekturen (Single Instruction Multiple Data), da blasen dann die angehängten Daten die Länge auf. Bei VLIW werden vielmehr mehrere einfache Befehle zu einem langen Befehlswort gebündelt.
Welchen Nutzen hat dies? Nun die erste Implementierung diente vor allem dazu, mit dem grundsätzlichen Manko des Speichers umzugehen. Schon immer war Speicher langsamer als die CPU. Das war schon in den Sechzigern so. Eine der Lösung die Langsamkeit auszugleichen war Bandbreite. Vereinfacht gesagt: wenn man auf die Daten schon warten musste, dann glich man dies dadurch aus, das man mehr Daten holte. Bei Daten hatten daher sehr oft die CPU mehr als einen Anschluss zum Speicher (oft Port genannt). Bei den Befehlen bestand die Lösung in VLIW: anstatt das der Decoder ein Wort holte, holte er ein langes Wort, das mehrere einzelne Worte enthielt. So musste er nicht auf die nachfolgenden Worte warten, sie waren schon in der CPU.
Die Cyber Star/203/205 Architektur hatte z.B. Befehlsworte von 64 Bit Länge, griff aber auf den Speicher immer in Superworten von 512 Bit zu die 8 Worte oder 16 einfach bzw. 8 doppelt genauen Zahlen oder eben acht Befehlen zu. Obwohl nicht zwingend erforderlich, sind viele VLIW Architekturen RISC Archietekturen. Das vereinfacht es, mehrere Befehle in ein VLIW zu packen, denn RISC Architekturen haben im Allgemeinen wesentlich weniger unterschiedliche Befehlslängen. Das erlaubt es einfacher ein VLIW zu dekodieren oder zumindest den Platz in einem VLIW auszunutzen ohne Leerbytes oder Leerbefehle einzufügen.
Man kann denselben Effekt wie ein Superwort aber auch einfach durch breite Datenbusse (heute z.B. in Grafikkarten verwendet) oder durch weiter vorrausschauenden Prefetch (x86 Architektur) erreichen. Bei den heutigen Architekturen haben VLIW Instruktionen einen anderen Sinn. Sie sind in der Regel superskalar. Das bedeutet ein Prozessor hat mehr als eine Ausführeinheit für Ganzzahl oder Fließkommaoperationen, bzw. heute oft auch für Daten/Adressen laden und Sprünge durchführen. Da der Code (anders als bei mehreren CPU-Kernen) aber nichts von den mehreren Einheiten weiß müssen CPUs mit dieser Architektur (superskalar genannt) schauen, dass sie alle Einheiten auslasten. Sehr bald zeigte sich das das schwer wird. Superkskalare Architekturen haben daher oft eine „Out-of-Order“ Architektur: Sie erkennen Abhängigkeiten zwischen den Befehlen und Daten und ziehen Befehle vor, wenn diese nicht von anderen abhängen. Eine solche Architektur braucht sehr viel Logic. Intel lies sie z.B. beim Atom Prozessor weg. Als er 2008 im 45 nm Prozess erschien, hatte er z.B. 42 Millionen Transistoren, die zeitgleich in derselben Fertigungstechnologie gefertigte „Penryn“ Mikroarchitektur dagegen 410 Millionen Transistoren (aber bei zwei Kernen). Allerdings erreichte diese erste Atomgeneration auch keine bessere Performance als ein 5 Jahre älterer Pentium 4 Prozessor.
VLIW eröffnet die Chance ohne diese aufwendige Logik auszukommen. Die dahinterstehende Idee ist, dass der Compiler der den Code kennt, die Worte so anordnet, dass alle Einheiten möglichst voll ausgelastet sind. Schafft er das nicht, so füllt er mit „Nichts Tun“ Befehlen auf. (NOP – No Operation). Bei der Texas Instruments TMS320C6xx Familie ist ein VLIW 256 Bit breit und besteht aus 8 Befehlen. Dieses wird in zwei Teile aufgeteilt, die zu den beiden Kernen geführt werden und jeder hat vier Ausführungseinheiten. Bei dieser Architektur klappte das auch sehr gut. Dazu trug ein Registerfile bei, bei dem es sehr viele Register gab, sodass Abhängigkeiten seltener als bei wenigen Registern vorkamen und die Harvard-Architektur die getrennte Daten- und Instruktionsbusse hat. zudem verarbeitete diese Architektur keine Fleißkommazahlen.
Derselbe Ansatz scheiterte aber beim Itanium-Prozessor, obwohl er dort noch ausgeklügelter war: In einem 128 Bit Wort gab es neben drei Befehlen à 41 Bits Breite noch 5 Bits um die Abhängigkeiten und benutzten Einheiten zu markieren. Damit kann der Compiler die CPU informieren wie die Befehle zu verarbeiten sind. Der Itaniumprozessor erreichte nie den Markterfolg den sich Intel erhoffte. Sehr bald überholten ihn auch x86 Prozessoren in der Performance. Woran es liegt? vielleicht hat der Itanium ein zu komplexes Innenleben denn bei ihm wollen auch noch einige Branchunits und Fließkommaeinheiten mit Daten versorgt werden, vielleicht ist der Code für Signalverarbeitung aber auch per se besser parallelisierbar oder die Compiler sind zu doof. Angesichts der ct‘-Ergebnisse der Matrizenmultiplikation die man heute durch einen einzigen AVX Befehl ersetzen kann wo CPUs nur einen Bruchteil der theoretischen Leistung erreichen, würde mich das nicht wundern.
Anders als SIMD hat sich die VLIW Architektur auf jeden Fall nicht auf breiter Front durchsetzen können.