Frage Warum versteckt Intel den internen RISC-Kern in seinen Prozessoren?


Beginnend mit Pentium Pro (P6-Mikroarchitektur) hat Intel seine Mikroprozessoren neu gestaltet und den internen RISC-Core unter den alten CISC-Anweisungen verwendet. Seit Pentium Pro werden alle CISC-Anweisungen in kleinere Teile (ups) unterteilt und dann vom RISC-Core ausgeführt.

Am Anfang war mir klar, dass Intel entschied, neue interne Architektur zu verstecken und Programmierer dazu zu zwingen, "CISC-Shell" zu verwenden. Dank dieser Entscheidung konnte Intel die Mikroprozessoren-Architektur komplett neu gestalten, ohne die Kompatibilität zu beeinträchtigen.

Allerdings verstehe ich eine Sache nicht, warum Intel immer noch eine interne RISC-Anleitung versteckt so viele Jahre versteckt hält? Warum sollten sie Programmierer RISC-Anweisungen wie die Verwendung alter x86 CISC-Anweisungen nicht verwenden lassen?

Wenn Intel so lange rückwärtskompatibel ist (wir haben immer noch den virtuellen 8086-Modus neben dem 64-Bit-Modus), warum lassen sie uns keine Programme kompilieren, so dass sie CISC-Anweisungen umgehen und den RISC-Kern direkt verwenden? Dies wird den natürlichen Weg öffnen, um langsam den x86-Befehlssatz zu verlassen, der heutzutage veraltet ist (das ist der Hauptgrund, warum Intel sich dafür entschieden hat, den RISC-Kern zu verwenden, nicht wahr?).

Wenn man sich die neue Intel Core i-Serie ansieht, sehe ich, dass sie nur die CISC-Anweisungen erweitert, die AVX, SSE4 und andere hinzufügen.


76
2018-04-27 15:27


Ursprung


Antworten:


Nein, der x86-Befehlssatz ist sicher nicht veraltet. Es ist so beliebt wie immer. Der Grund, warum Intel intern eine Reihe von RISC-ähnlichen Mikrobefehlen verwendet, liegt darin, dass sie effizienter verarbeitet werden können.

Eine x86-CPU arbeitet also mit einem ziemlich robusten Decoder im Frontend, der x86-Anweisungen akzeptiert und in ein optimiertes internes Format konvertiert, das vom Backend verarbeitet werden kann.

Um dieses Format "externen" Programmen zugänglich zu machen, gibt es zwei Punkte:

  • Es ist kein stabiles Format. Intel kann es zwischen CPU-Modellen ändern, um der spezifischen Architektur am besten zu entsprechen. Dies ermöglicht es ihnen, die Effizienz zu maximieren, und dieser Vorteil wäre verloren, wenn sie sich auf ein festes, stabiles Befehlsformat für die interne Verwendung sowie die externe Verwendung festlegen müssten.
  • Es ist einfach nichts zu gewinnen, wenn man es macht. Mit den heutigen riesigen, komplexen CPUs ist der Decoder ein relativ kleiner Teil der CPU. Das Dekodieren von x86-Befehlen macht das komplexer, aber der Rest der CPU ist davon nicht betroffen, so dass insgesamt nur wenig zu gewinnen ist, insbesondere weil das x86-Frontend immer noch da sein müsste, um "Legacy" -Code auszuführen . Sie sparen also nicht einmal die Transistoren, die derzeit am x86-Frontend verwendet werden.

Dies ist keine perfekte Anordnung, aber die Kosten sind ziemlich klein und es ist eine viel bessere Wahl, als die CPU zu entwerfen, um sie zu unterstützen zwei völlig unterschiedliche Befehlssätze. (In diesem Fall würden sie wahrscheinlich am Ende einen dritte Satz von Mikro-Ops für den internen Gebrauch, nur weil diese frei justiert werden können, um der internen Architektur der CPU am besten zu entsprechen)


78
2018-04-27 15:38



Wenn Intel Abwärtskompatibilität hält   so lange (wir haben immer noch virtuell   8086-Modus neben 64-Bit-Modus), Warum   erlauben sie uns nicht, Programme zu kompilieren   damit umgehen sie CISC-Anweisungen   und RISC-Kern direkt verwenden? Dieser Wille   Öffne den natürlichen Weg, um x86 langsam zu verlassen   Anweisungen festgelegt, die veraltet ist   heutzutage (das ist der Hauptgrund, warum   Intel entschied sich dafür, RISC-Core zu verwenden,   Recht?).

Sie müssen den geschäftlichen Aspekt davon betrachten. Intel hat tatsächlich versucht, weg von x86, aber es ist die Gans, die goldene Eier für das Unternehmen legt. XScale und Itanium waren nie annähernd so erfolgreich wie ihr x86-Kerngeschäft.

Was Sie im Grunde fragen, ist, dass Intel seine Handgelenke im Austausch für warme Fuzzies von Entwicklern schneidet. X86 zu untergraben ist nicht in ihrem Interesse. Alles, was mehr Entwickler dazu bringt, sich nicht auf x86 zu konzentrieren, untergräbt x86. Das wiederum untergräbt sie.


15
2018-04-27 15:43



Die wirkliche Antwort ist einfach.

Der Hauptgrund für die Implementierung von RISC-Prozessoren bestand darin, die Komplexität zu reduzieren und Geschwindigkeit zu erhöhen. Der Nachteil von RISC ist die reduzierte Befehlsdichte, dh der gleiche Code, der im RISC-ähnlichen Format ausgedrückt wird, benötigt mehr Anweisungen als der entsprechende CISC-Code.

Dieser Nebeneffekt bedeutet nicht viel, wenn Ihre CPU mit der gleichen Geschwindigkeit wie der Speicher läuft, oder zumindest wenn sie beide mit einigermaßen ähnlichen Geschwindigkeiten laufen.

Derzeit zeigt die Speichergeschwindigkeit im Vergleich zur CPU-Geschwindigkeit einen großen Unterschied in den Takten. Aktuelle CPUs sind manchmal fünfmal oder schneller als der Hauptspeicher.

Dieser Stand der Technik begünstigt einen dichteren Code, etwas, das CISC bietet.

Sie können argumentieren, dass Caches RISC-CPUs beschleunigen könnten. Aber das gleiche kann über CISC-Cpus gesagt werden.

Sie erhalten eine größere Geschwindigkeitsverbesserung durch die Verwendung von CISC und Caches als durch RISC und Caches, da der Cache mit der gleichen Größe mehr Auswirkungen auf den Code mit hoher Dichte hat, den CISC bietet.

Ein weiterer Nebeneffekt ist, dass RISC die Implementierung des Compilers erschwert. Es ist einfacher, Compiler für CISC-Cpus zu optimieren. etc.

Intel weiß, was sie tun.

Dies ist so wahr, dass ARM einen höheren Code-Dichte-Modus namens Thumb hat.


13
2018-03-23 23:07



Die Antwort ist einfach. Intel entwickelt keine CPUs für Entwickler! Sie entwickeln sie für die Leute, die das machen Einkauf Entscheidungen, die BTW, ist was jedes Unternehmen auf der Welt tut!

Intel hat sich schon vor langer Zeit dazu verpflichtet, ihre CPUs (im Rahmen des Zumutbaren natürlich) rückwärts kompatibel zu halten. Die Leute wollen das wissen, wenn sie einen neuen Intel-basierten Computer kaufen alle der aktuellen Software wird genauso laufen wie auf ihrem alten Computer. (Obwohl, hoffentlich, schneller!)

Darüber hinaus weiß Intel genau Wie wichtig ist diese Verpflichtung, weil sie einmal versucht haben, einen anderen Weg zu gehen. Genau wie viele Menschen Sie Mit einer Itanium-CPU umgehen?!?

Sie mögen es vielleicht nicht, aber diese Entscheidung, mit dem x86 zu bleiben, hat Intel zu einem der bekanntesten Business-Namen der Welt gemacht!


4
2017-10-10 00:27



Die Antwort von jalf deckt die meisten Gründe ab, aber es gibt ein interessantes Detail, das nicht erwähnt wird: Der interne RISC-ähnliche Kern ist nicht dafür ausgelegt, einen Befehlssatz wie ARM / PPC / MIPS auszuführen. Die x86-Steuer wird nicht nur in den leistungshungrigen Decodern bezahlt, sondern zu einem gewissen Grad im gesamten Kern. es ist nicht nur die x86-Befehlscodierung; es ist jede Instruktion mit seltsamer Semantik.

Nehmen wir an, dass Intel einen Betriebsmodus erstellt hat, in dem der Befehlsstrom etwas anderes als x86 war, mit Anweisungen, die uops direkter zugeordnet wurden. Lassen Sie uns auch so tun, als ob jedes CPU-Modell seinen eigenen ISA für diesen Modus hat, so dass es ihnen freisteht, die Interna zu ändern, wenn sie möchten, und sie mit einer minimalen Anzahl von Transistoren für die Befehlsdekodierung dieses alternativen Formats auszustatten.

Vermutlich hätten Sie immer noch nur die gleiche Anzahl von Registern, die dem x86-Architekturstatus zugeordnet sind, so dass x86-Betriebssysteme sie auf Kontextwechsel speichern / wiederherstellen können, ohne den CPU-spezifischen Befehlssatz zu verwenden. Dies ist wahrscheinlich nicht zu schwierig, da die Hardware für das Umbenennen von Registern bereits existiert. (interne UPs beziehen sich tatsächlich auf die physische Registerdatei, aber unsere hypothetische RISC-ISA müsste das nicht).


Wenn wir nur alternative Decoder haben, ohne Änderungen an späteren Pipelinestufen (Ausführungseinheiten), Diese ISA würde immer noch viele x86 Exzentrizitäten haben.  Es wäre keine sehr schöne RISC-Architektur. Keine einzelne Anweisung wäre sehr komplex, aber einige der anderen Verrücktheiten von x86 wären immer noch da.

Zum Beispiel: Links / Rechts-Verschiebungen lassen das Überlauf-Flag undefiniert, es sei denn, der Verschiebungs-Zählwert ist Eins, in welchem ​​Fall OF = die übliche Vorzeichenüberlauf-Erkennung ist. Ähnliche Verrücktheit für rotiert. Die exponierten RISC-Befehle könnten jedoch Flag-like-Verschiebungen und so weiter bereitstellen (was die Verwendung von nur einem oder zwei der mehreren UPs ermöglicht, die normalerweise in einige komplexe x86-Anweisungen eingehen). Das hält also nicht wirklich als Hauptgegenargument.

Wenn Sie einen komplett neuen Decoder für eine RISC-ISA erstellen wollen, können Sie Teile von x86-Anweisungen auswählen und auswählen lassen, die als RISC-Anweisungen verfügbar gemacht werden sollen. Dies mildert die x86-Spezialisierung des Kerns etwas ab.


Die Befehlskodierung würde wahrscheinlich keine feste Größe haben, da einzelne UPs eine Menge Daten speichern können. Viel mehr Daten als sinnvoll, wenn alle Insns gleich groß sind. Ein einzelner mikrofusionierter UOP kann einen 32-Bit-Sofort- und einen Speicheroperanden hinzufügen, der einen Adressierungsmodus mit 2 Registern und einer 32-Bit-Verschiebung verwendet. (In SnB und später können nur Einzelregister-Adressierungsmodi mit ALU-Operationen mikrofusioniert werden).

Ups sind sehr groß und nicht sehr ähnlich zu ARM-Anweisungen mit fester Breite. Ein 32-Bit-Befehlssatz mit fester Breite kann nur 16-Bit-Sofortnachrichten gleichzeitig laden. Daher erfordert das Laden einer 32-Bit-Adresse ein Load-Unmittelbares Low-Half / LoadHigh-Direct-Paar. x86 muss das nicht tun, was es nicht scheußlich macht, wenn nur 15 GP-Register die Fähigkeit einschränken, Konstanten in Registern herumzuhalten. (15 ist eine große Hilfe über 7 Register, aber die erneute Verdoppelung auf 31 hilft viel weniger, ich denke, einige Simulation gefunden. RSP ist in der Regel nicht allgemeingültig, so ist es mehr wie 15 GP-Register und einen Stapel.)


TL; DR Zusammenfassung:

Wie auch immer, diese Antwort läuft darauf hinaus, dass "der x86-Befehlssatz wahrscheinlich der beste Weg ist, eine CPU zu programmieren, die x86-Anweisungen schnell ausführen kann", aber hoffentlich beleuchtet er die Gründe.


2
2017-09-30 13:00



Warum erlauben sie uns nicht, Programme zu kompilieren, damit sie CISC-Anweisungen umgehen und den RISC-Kern direkt verwenden?

Ein weiterer Grund ist neben den bisherigen Antworten die Marktsegmentierung. Es wird davon ausgegangen, dass einige Anweisungen eher in Mikrocode als in Hardware implementiert werden, so dass jeder, der beliebige Mikrooperationen ausführen kann, die Verkäufe von neuen CPUs mit "neuen" leistungsfähigeren CISC-Befehlen untergraben kann.


-3
2017-10-15 15:49