ISA vergibt keine Fehler

–X86 ist ein historisches Missverständnis, - der Meister und in 80 verlor nicht die polemische Begeisterung.
"Eigentlich besitzt sie 95% des Servermarktes", antwortete ich träge. Ich wollte nicht über ein hundertmal abgedroschenes Thema streiten
- und ich bin bereits in diesen Präfixen verwirrt -, der Akademiker gab nicht nach. - 15 Bytes pro Befehl, das ist undenkbar!
- Natürlich kein Eis. Aber wer ist besser?
- Ja, irgendjemand, zumindest ARM-a.
"Ich verstehe immer noch nicht." Additionen mit Multiplikationen sollten sein?
- Sollte.
- Und verschiebt sich mit logischen Operationen?
- Ja.
- Und Downloads mit Speichern auch. Was ist der Unterschied darin, wie sie aufgerufen und codiert werden?

Wie immer wurde mir die Richtigkeit des Lehrers viel später klar. Als ich mich an einem trostlosen Winterabend hinsetzte, um einen Befehlsdecoder zu schreiben, um mich irgendwie zu amüsieren. Ich habe es geschafft, in ein paar Tagen einen einfachen Decoder für ARM auf VHDL darzustellen (und ich weiß es so lala). Es stimmt, ich bereue, ich hatte einen Spickzettel. :)



Für X86 war es für eine Woche oder für zwei oder für einen Monat nicht möglich ... Selbst für das Basisset.

Der Unterschied besteht hier nicht nur in RISC (Reduced Instruction Set Computing) für ARM und CISC (Complex Instruction Set) für X86. Der Unterschied liegt eher auf dem Weg der historischen Entwicklung. Vor mehr als 40 Jahren, und alles begann 1978, war die X86 ISA (Instruction Set Architecture) ein recht kompakter Befehlssatz mit eigener interner Logik. Aber die Zeit verging, die Buskapazität nahm zu, die Register wurden erweitert (einschließlich SIMD) und die Anzahl der Teams wuchs ständig. Dann machte ein Mann einen interessanten Versuch, einfach die Anzahl der Anweisungen in X86 zu zählen. Ob er zu faul war, um das Handbuch zu öffnenund zähle sie, entweder wusste er von der Existenz „namenloser“ Opcodes (Teams, die nicht einmal einen Namen haben) oder er glaubte an die Allmacht der Logik. Es ist leicht zu verstehen, dass sich die Logik als machtlos herausstellte. :) Übrigens habe ich versucht, eine grafische Darstellung des Anstiegs der Anzahl der X86-Anweisungen nach Jahr (oder nach Generation) zu finden. Ich konnte es noch nicht (vielleicht hat es jemand?). Aber ich habe hier so ein Bild gefunden .



Um ehrlich zu sein, weiß ich nicht, wie viele Anweisungen der X86 ISA enthält. Aber ich erinnere mich gut an all die, die ich selbst in die Entwicklung investiert habe, ohne zu bemerken, dass jedes neue Stück in ISA als „für immer behalten“ gekennzeichnet ist. Und es gab mehrere tausend "Schöpfer" wie mich bei Intel. Und die Teile, um all ihre Fantasien zu kodieren, fehlten ständig. :) Alle neuen Präfixe wurden dem vorhandenen Befehlssatz hinzugefügt: REX, VEX ... Die letzte 4-Byte-Erweiterung (EVEX) wurde für den AVX-512 eingeführt. Übrigens wird der gesamte Satz von ARM-Befehlen (auch unter Berücksichtigung von SVE ) in denselben 4 Bytes entfernt. ARM ging zunächst den umgekehrten Weg und baute sein Befehlssystem auf den Grundprinzipien Einfachheit, Kompaktheit und Erweiterbarkeit auf.

Der Unterschied kann verstanden werden, wenn wir vom Standpunkt des Programmierers zum Standpunkt des Schaltungsentwicklers wechseln. Und es ist bekannt, dass der Transistor eine großartige Sache ist, aber er schaltet langsam und leitet schamlos Energie ab. Und wenn andere Dinge gleich sind, wäre es besser, wenn es weniger gäbe. Schauen Sie sich nun den Decodierungsalgorithmus für x86-Anweisungen an (das Problem, das ich zu lösen versuchte).



Und wie sie sagen, spüren Sie den Unterschied in den Eingabepfaden (Frontend) für ARM und X86. Hier kann argumentiert werden, dass das Frontend ein sehr kleiner Teil des Kernels ist, nur etwa 10%. Ja, aber vergessen Sie nicht, dass all diese Logik mit der Anzahl der Kerne auf dem Chip multipliziert wird. Und das ist ernst.

Eine weitere Überlegung ist, dass das Frontend nur der Teil ist, der für die Abwärtskompatibilität verantwortlich ist. Sie können sicher schaufeln oder sogar das hintere Ende werfen. Intel nutzte dies übrigens Anfang der 2000er Jahre und ersetzte die NetBurst (P4) -Architektur durch Core-M (P3). Das Frontend kann aber nicht stark reduziert werden. Obwohl ich manchmal wirklich möchte, werden aufgrund der vorhandenen X86-ISA jetzt ungefähr 20% verwendet. Der Rest sind Überreste der Vergangenheit.

Ein weiterer Nachteil der großen Länge von Befehlen sind die relativ häufigen Fehler im Befehls-Cache. Grob gesagt ist bei gleicher Cache-Größe die Anzahl der Fehler umso größer, je länger der Befehl ist. Natürlich kann die Größe der Caches erhöht werden. Andererseits sind dies Transistoren, die es möglicherweise nicht gegeben hätten, wenn die Anweisungen kürzer gewesen wären. Aus dem gleichen Grund bin ich sehr vorsichtig mit verschiedenen Arten von VLIW-Architekturen (Very Long Instruction World). Sie haben jedoch auch den Nachteil, dass es für sie sehr schwierig ist, Compiler zu entwickeln. Bisher habe ich das Thema Compiler bewusst vermieden, da ich sie nie selbst entwickelt habe. Ich würde gerne hören, was Fachleute über die Freuden der Entwicklung von Compilern für RISC, CISC und VLIW sagen werden.

Und doch waren die X86-Entwickler trotz der enormen Menge an Vermächtnis und vielleicht dank ihm in der Hauptsache richtig. Das Prinzip der Abwärtskompatibilität wurde in der Architektur von Anfang an eingehalten. Die gesamte vorhandene Software funktioniert sofort auf der neuen Hardware. Dies ermöglichte es, ein so tiefes und entwickeltes Ökosystem rund um die Architektur aufzubauen. Und es bleibt nur noch abzuheben, bevor die Ingenieure von Intel und AMD, die trotz des überhaupt nicht perfekten ISA-Designs seit vielen Jahren die Führung im Serversegment behalten. Die Legacy-Last wird jedoch immer schwieriger.