VLIW<\/a> nennt – very Long instruction Word. Dieser Ansatz soll zum einen die Abhängigkeit vom dem Speichersystem reduzieren, dass viel langsamer als der Prozessor ist – man überträgt nicht einen Befehl sondern mehrere, die man zu einem Superwort zusammenfasst. Das Konzept gibt es auch bei Signalverarbeitungsprozessoren und die Cyber Star setzte es auch ein. Das zweite ist das heute alle Prozessoren nicht nur mehrere Kerne haben, sondern jeder Kern auch mehrere Recheneinheiten. Während die Kerne aber nach außen hin sichtbar sind, sind es die Funktionseinheiten nicht. Die Prozessoren versuchen mit einigen Tricks diese Einheiten alle auszulasten sogar indem sie die Befehlsreihenfolge verändern. Der Itanium wollte diese aufwendige Logik einsparen und delegierte die Aufgabe an den Compiler. Einige Bits im Superwort enthielten die Informationen welche Befehle parallel ablaufen konnten und welche nicht. So richtig gelang dies nicht, denn die Performance war immer nur mittelmäßig. Folgerichtig stellte Intel auch diese Entwicklung ein.<\/p>\nDie Chancen, dass ein Compiler optimalen Code erzeugt sind um so besser, je weniger Befehle ein Prozessor hat. Untersuchungen von Kompiliertem Code bei den damals üblichen CISC Prozessoren ergab, dass vom gesamten Befehlssatz nur ein Bruchteil sehr häufig benutzt wurde, manche Befehle niemals. Das war damals der Startschuss für RISC – ein kleinerer Befehlssatz sollte schneller ausgeführt werden. Heute arbeiten die x86 und x64 Prozessoren intern auch mit RISC, sie machen einen Zwischenschritt und übersetzen den CISC Code in RISC. das zeigt schon die Problematik. Trotzdem führte Intel mit MMX, SSE 1-4 und AVX 1+2 immer neue Befehle ein, das mit wurde der Befehlssatz noch komplizierter und die Wahrscheinlichkeit, das der Compiler die beste Lösung findet schwindet, zumal er ja nur eine Vorschrift anwendet.<\/p>\n
Was ist die Lösung? Nun OpenMP zeigt eine Lösung auf. Bei OpenMP, das bei Microsofts und Intels Compiler die Performance deutlich erhöhte, gibt der Programmierer an was parelellisierbar ist. Offenbar sind diese immer noch schlauer als die Compiler. Das zeigte auch der Code denn mein Compiler erzeugte. Dort wurde ich an eine Optimierung der Core 2 Architektur erinnert. Es handelt sich um den Befehl „Speichere Daten an Adresse X“ gefolgt wenige Befehle später von „Lade Daten von Adresse X“. Für einen Programmierer erscheint diese Sequenz dämlich, denn erst speichere ich einen Wert dann hole ich ihn, stattdessen kann ich ihn gleich in einem Register halten, das ist viel schneller. Obwohl nur vier der acht FPU Register genutzt wurden, fand sich genau diese Kombination im Code in dieser Zeile. Bei der Core 2 Mikroarchitektur hat man diese das Umsortieren der Befehle aufhaltende Kombination erkannt und sie blockiert nicht mehr das Umsortieren.<\/p>\n
Das zeigt: Compiler sind heute noch strunz doof. Der Compiler hätte eigentlich so viel wie möglich in den Registern halten müssen denn der Speicherzugriff ist auch noch langsam. Was folgt daraus? Meine persönliche Ansicht nach sollte man das ursprüngliche Ziel von RISC beibehalten. Anstatt das Innenleben der CPU umzumodeln, damit sie das beste aus dem Code herauskitzeln, indem sie spekulative Sprünge vorhersagen, Register umbenennen, Befehle umsortieren oder Zugriffsmuster auf den Speicher vorhersagen sollte man wenige Befehle sehr schnell ausführen und das geht zum einen mit RISC zum andern mit Eingehen auf den Compiler. Beispielsweise übergeben die meisten Compiler Parameter an Funktionen über den Stack – nicht nur fehlerträchtig, sondern auch langsam.<\/p>\n
Stattdessen sollte man für jede Routine eigene Register für die Parameterübergabe zur Verfügung stellen, die man als Fenster aus einem größeren Registerfile auswählt. Dieses Konzept des Registerfiles kennen einige RISC Architekturen. Anders als beim Cache kann der Compiler so viel besser kontrollieren wo die Daten gespeichert werden. Das gilt auch für das Laden von Routinen. Der Compiler weriß wie groß ein Unterprogramm ist und könnte es vorrausschauend in den Cache laden lassen. Auch das Konzept des VLIW ist nicht so dumm. Zumindest wäre es möglich in einem Statusbyte oder einigen Bits pro Befehl anzugeben welche Einheit man nutzt. Gleiche Werte erlauben es dem Prozessor zu erkennen: okay diese Befehle hängen voneinander ab. Man kann mit einem Befehl eine Einheit für eine Befehlssequenz reservieren und wieder freigeben.<\/p>\n
Das sind nur einige Ideen, aber je mehr ich über Mikroarchitekturen schreibe, derzeit bin ich bei Nehalem, also der drittletzten Architektur die 2008n erschien, desto mehr wird mir klar, dass man eine ganze Menge Aufwand betreibt um im Prozessor die Performance zu steigern, ohne das der Anwender das heute groß mit dem Compiler beeinflussen könnte. Dabei kennt der den Quelltext er kennt Zugriffsmuster und er weiß wo Routinen sind die häufig gebraucht werden und welche wo langsam sind, bzw., welche als nächstes dran kommen (die man schon mal vom Speicher in den Cache geladen werden können). Man sollte also die Zusammenarbeit intensivieren anstatt neue CISD Befehle zu kreieren.<\/p>\n
Es gäbe sogar eine noch weitergehende Möglichkeit: die des Profilings. Das gibt es heute als Tools für Entwicklungsstudios, aber es wurde auch bei PC’s eingesetzt die auf dem Alpha Prozessor basierten und für x86 geschriebene Programme als Emulation ausführten: Ein Programm wird zuerst einfach in Maschinensprache übersetzt und vom Anwender normal benutzt. Dabei führt ein mitgeliefertes Modul Buch wie oft welche Routine ausgeführt wird, auf welche Variablen zugegriffen wird etc. Das kann man ausbauen und auch zeitliche Zusammenhänge erkennen (eine Routine wird kurzzeitig sejr oft aufgerufen, dann wieder längere Zeit gar nicht). In einem zweiten Schritt wird das Programm neu übersetzt wobei die Informationen genutzt werden es zu optimieren. Ohne spezielle SIMD Befehle z.B. Variablen in Registern dauerhaft zu halten oder zumindest im Cache, Routinen vorbeugend laden wenn man weiß das sie oft nach anderen aufgerufen werden. Man kann es aber auch nutzen um CISC Befehle wie obigen FMA zu nehmen indem man beim lauf das Zugriffsmuster und die Operationen in einem Array erkennt.
\n![\"\"](\"http:\/\/vg01.met.vgwort.de\/na\/9263e49756ed40eaa564f9df89e0fd2f\")
<\/p>\n","protected":false},"excerpt":{"rendered":"
Ein Compiler hat die Aufgabe eine höhere Programmiersprache in Maschinensprache zu übersetzen. Bei Großrechnern haben kompilierte Programme schon in den Sechzigern die Maschinensprache sukzessive verdrängt. Im PC Bereich war wegen der anfangs langsamen Prozessoren und dem geringen Speicher Assembler noch in den ersten Jahren wichtig, aber heute sicher nicht mehr. Machen wir einen geschichtlichen Rückblick. […]<\/p>\n","protected":false},"author":169,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[4],"tags":[3780,3673,3782,3781,3779],"class_list":["post-10614","post","type-post","status-publish","format-standard","hentry","category-computer","tag-avx","tag-compiler","tag-i860","tag-itanium","tag-sse","entry"],"a3_pvc":{"activated":false,"total_views":1021,"today_views":0},"jetpack-related-posts":[{"id":18676,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/05\/31\/die-glorreichen-10-programmiersprachen\/","url_meta":{"origin":10614,"position":0},"title":"Die glorreichen 10 \u2013 Programmiersprachen","author":"Bernd Leitenberger","date":"31.05.2026","format":false,"excerpt":"Ich wollte mal eine Reihe in dieser Rubrik \u00fcber Programmiersprachen machen. Zuerst dachte ich daran eine Liste nach meinen pers\u00f6nlichen Favoriten zu erstellen. Anfangs bef\u00fcrchtete ich, dass ich gar nicht auf 10 komme, aber es sind tats\u00e4chlich mehr, wenngleich ich in vielen Sprachen nur kleine Programme verfasst habe oder mich\u2026","rel":"","context":"In "Die Glorreichen 10"","block_context":{"text":"Die Glorreichen 10","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/allgemein\/die-glorreichen-10\/"},"img":{"alt_text":"","src":"https:\/\/vg09.met.vgwort.de\/na\/4073c4f9dc6943a08702cdde13605d43","width":350,"height":200},"classes":[]},{"id":18683,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/06\/01\/die-glorreichen-10-programmiersprachen-2\/","url_meta":{"origin":10614,"position":1},"title":"Die glorreichen 10 \u2013 Programmiersprachen (2)","author":"Bernd Leitenberger","date":"01.06.2026","format":false,"excerpt":"Der heutige Teil schlie\u00dft nahtlos an den ersten Teil an, der gestern erschien. Es geht um 10 Kriterien anhand derer man Programmiersprachen kategorisieren kann. Maschinennah oder universell, aber komplex Als eine maschinennahe Sprache bezeichnet man eine Sprache, die nahe den M\u00f6glichkeiten von Prozessoren ist. Das Paradebeispiel ist C. Alle Prozessoren\u2026","rel":"","context":"In "Die Glorreichen 10"","block_context":{"text":"Die Glorreichen 10","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/allgemein\/die-glorreichen-10\/"},"img":{"alt_text":"","src":"https:\/\/vg09.met.vgwort.de\/na\/7f5d9cf5265047179df05b778bf455b5","width":350,"height":200},"classes":[]},{"id":18610,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/03\/27\/galileos-cds-teil-1\/","url_meta":{"origin":10614,"position":2},"title":"Galileos CDS – Teil 1","author":"Bernd Leitenberger","date":"27.03.2026","format":false,"excerpt":"Hall\u00f6chen, es wird Zeit das ich mich mal wieder melde. Es gab zwei Gr\u00fcnde, warum ich mich so rar gemacht habe. Das eine ist das es gerade nicht so viel aktuelles gibt, au\u00dfer einem Update zu Artemis, zu dem ich vielleicht noch etwas schreibe. W\u00e4hrend Trump das ganze Programm nach\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg07.met.vgwort.de\/na\/4fb81c7bafbd4d9d88b5695abdb33d29","width":350,"height":200},"classes":[]},{"id":18888,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/08\/27\/die-ki-nachlese-nach-drei-jahren\/","url_meta":{"origin":10614,"position":3},"title":"Die KI – Nachlese nach drei Jahren","author":"Bernd Leitenberger","date":"27.08.2026","format":false,"excerpt":"Als die KI vor einigen Jahren aufkam, konnte man ihr noch etliche Tatsachen unterschieben. Ich empfehle, meinen Beitrag \u201eMariner\u202f10 und ChatGPT\u201c mal durchzulesen. Der Beitrag ist sehr humorvoll zu lesen, weil die KI fabuliert und sich auch entschuldigt, wenn man der KI v\u00f6lligen Unsinn als Tatsache vorsetzt. Selbst Bilder waren\u2026","rel":"","context":"In "KI"","block_context":{"text":"KI","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/ki\/"},"img":{"alt_text":"","src":"\/img\/nightcafebild.jpg","width":350,"height":200,"srcset":"\/img\/nightcafebild.jpg 1x, \/img\/nightcafebild.jpg 1.5x, \/img\/nightcafebild.jpg 2x, \/img\/nightcafebild.jpg 3x"},"classes":[]},{"id":18612,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/03\/28\/galileos-cds-teil-2\/","url_meta":{"origin":10614,"position":4},"title":"Galileos CDS \u2013 Teil 2","author":"Bernd Leitenberger","date":"28.03.2026","format":false,"excerpt":"So, heute geht es weiter mit Teil 2 \u00fcber Galileos CDS, dieser Beitrag schlie\u00dft nahtlos an den ersten Beitrag von gestern an, wie man schon an der ersten Textzeile sieht. Nach der Einleitung im ersten Teil geht es heute weiter damit warum der RCA 1802 genutzt wurde und was seine\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg07.met.vgwort.de\/na\/191e4b0728de42829cf656027b84dc82","width":350,"height":200},"classes":[]},{"id":18614,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/03\/29\/galileos-cds-teil-3\/","url_meta":{"origin":10614,"position":5},"title":"Galileos CDS – Teil 3","author":"Bernd Leitenberger","date":"29.03.2026","format":false,"excerpt":"So nun zum dritten Teil \u00fcber das prim\u00e4re Computersystem von Galileo, das CDS. Nachdem sich die ersten beiden Teile nur mit dem RCA 1802, warum er gew\u00e4hlt wurde und seiner Architektur befassten geht es heute um das Computersystem selbst. Der Artikel schlie\u00dft so an seine beiden Vorg\u00e4nger gestern und vorgestern\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg07.met.vgwort.de\/na\/6e7f572a246b4ac395de9c260733b707","width":350,"height":200},"classes":[]}],"jetpack_sharing_enabled":true,"amp_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/posts\/10614","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/users\/169"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/comments?post=10614"}],"version-history":[{"count":0,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/posts\/10614\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/media?parent=10614"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/categories?post=10614"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/tags?post=10614"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}