web-dev-qa-db-ger.com

Warum ist x86 hässlich? Warum wird es im Vergleich zu anderen als minderwertig angesehen?

Vor kurzem habe ich einige SO Archivdateien gelesen und bin auf Aussagen gegen die x86-Architektur gestoßen.

und viele weitere Kommentare wie

Ich habe versucht zu suchen, aber keinen Grund gefunden. Ich finde x86 wahrscheinlich nicht schlecht, weil dies die einzige Architektur ist, mit der ich vertraut bin.

Kann mir jemand freundlicherweise Gründe dafür nennen, x86 im Vergleich zu anderen als hässlich/schlecht/minderwertig zu bezeichnen.

98
claws

Einige mögliche Gründe dafür:

  1. x86 ist ein relativ alter ISA (seine Vorfahren waren immerhin 8086er)
  2. x86 hat sich mehrmals erheblich weiterentwickelt, es ist jedoch Hardware erforderlich, um die Abwärtskompatibilität mit alten Binärdateien aufrechtzuerhalten. Beispielsweise unterstützt moderne x86-Hardware immer noch die native Ausführung von 16-Bit-Code. Darüber hinaus gibt es mehrere Speicheradressierungsmodelle, mit denen älterer Code auf demselben Prozessor zusammenarbeiten kann, z. B. im Real-Modus, im geschützten Modus, im virtuellen 8086-Modus und im (AMD64) -Long-Modus. Dies kann für manche verwirrend sein.
  3. x86 ist eine CISC-Maschine. Lange Zeit bedeutete dies, dass es langsamer war als RISC-Maschinen wie MIPS oder ARM, da Befehle Datenabhängigkeit und Flags aufweisen, was die Implementierung der meisten Formen der Parallelität auf Befehlsebene schwierig macht. Moderne Implementierungen übersetzen die x86-Anweisungen in RISC-ähnliche Anweisungen mit der Bezeichnung " micro-ops ", um diese Art von Optimierungen für die Implementierung in Hardware praktisch zu machen.
  4. In mancher Hinsicht ist das x86 nicht minderwertig, es ist nur anders. Beispielsweise wird die Eingabe/Ausgabe auf den meisten Architekturen als Speicherzuordnung behandelt, auf dem x86 jedoch nicht. (Hinweis: Moderne x86-Computer verfügen normalerweise über eine Form von DMA -Unterstützung und kommunizieren mit anderer Hardware über die Speicherzuordnung.) ISA hat noch I/O-Anweisungen wie IN und OUT)
  5. Das x86 IST EIN mit nur wenigen Architekturregistern, durch die Programme häufiger als sonst zum Roundtrip durch den Speicher gezwungen werden können notwendig. Die dafür erforderlichen zusätzlichen Anweisungen beanspruchen Ausführungsressourcen, die für nützliche Arbeiten aufgewendet werden könnten, obwohl effiziente Speicherweiterleitung die Latenz gering hält. Moderne Implementierungen mit dem Umbenennen von Registern in eine große physische Registerdatei können viele Anweisungen im Flug halten, aber das Fehlen von Architekturregistern war immer noch eine erhebliche Schwachstelle für 32-Bit-x86. Die Erhöhung von x86-64 von 8 auf 16 Ganzzahl- und Vektorregister ist einer der größten Faktoren dafür, dass 64-Bit-Code schneller als 32-Bit ist (zusammen mit dem effizienteren Registeraufruf ABI), nicht die größere Breite jedes Registers. Ein weiterer Anstieg von 16 auf 32 Integer-Register würde einigen helfen, aber nicht so viel. (AVX512 erhöht sich jedoch auf 32 Vektorregister, da Gleitkommacode eine höhere Latenz aufweist und häufig mehr Konstanten benötigt.) ( see comment )
  6. x86-Assemblycode ist kompliziert, da x86 eine komplizierte Architektur mit vielen Funktionen ist. Eine Anweisungsliste für ein typisches MIPS-Gerät passt auf ein einzelnes Stück Papier im Letter-Format. Die entsprechende Auflistung für x86 füllt mehrere Seiten aus, und die Anweisungen leisten einfach mehr, sodass Sie häufig eine ausführlichere Erläuterung ihrer Funktionsweise benötigen, als eine Auflistung bieten kann. Zum Beispiel benötigt die Anweisung MOVSB einen relativ großen Block C-Code, um zu beschreiben, was sie tut:

    if (DF==0) 
      *(byte*)DI++ = *(byte*)SI++; 
    else 
      *(byte*)DI-- = *(byte*)SI--;
    

    Dies ist ein einzelner Befehl, der ein Laden, Speichern und zwei Addieren oder Subtrahieren (gesteuert durch eine Flag-Eingabe) ausführt, die jeweils separate Befehle auf einer RISC-Maschine wären.

    Während MIPS (und ähnliche Architekturen) aufgrund ihrer Einfachheit nicht unbedingt überlegen sind, ist es für das Unterrichten einer Einführung in die Assembler-Klasse sinnvoll, mit einer einfacheren [~ # ~] isa [~ # ~ zu beginnen ] . Einige Assembly-Klassen enthalten eine extrem vereinfachte Teilmenge von x86 mit der Bezeichnung y86 , die über den Punkt hinaus vereinfacht wird, dass sie für den tatsächlichen Gebrauch nicht nützlich sind (z. B. keine Schichtanweisungen), oder einige Lehren Sie nur die grundlegenden x86-Anweisungen.

  7. Der x86 verwendet Opcodes variabler Länge, die die Hardware in Bezug auf das Parsen von Befehlen komplexer machen. In der modernen Ära werden diese Kosten immer geringer, da CPUs mehr und mehr durch die Speicherbandbreite als durch die unformatierte Berechnung begrenzt werden. Viele Artikel und Einstellungen zum "x86-Bashing" stammen jedoch aus einer Zeit, in der diese Kosten vergleichsweise viel höher waren.
    Update 2016: Anandtech hat eine Diskussion bezüglich Opcode-Größen unter x64 und AArch64 veröffentlicht.

BEARBEITEN: Dies soll keine Bash the x86! Party sein. Ich hatte keine andere Wahl, als ein bisschen zu hämmern, wie es die Frage formuliert. Mit Ausnahme von (1) wurden all diese Dinge aus guten Gründen getan (siehe Kommentare). Intel-Designer sind nicht dumm - sie wollten einige Dinge mit ihrer Architektur erreichen, und dies sind einige der Steuern, die sie zahlen mussten, um diese Dinge Wirklichkeit werden zu lassen.

85
Billy ONeal

Das Hauptproblem bei x86 ist in meinen Augen die CISC-Herkunft - der Befehlssatz enthält viele implizite Abhängigkeiten. Diese Interdependenzen erschweren die Neuordnung von Befehlen auf dem Chip, da die Artefakte und die Semantik dieser Interdependenzen für jeden Befehl beibehalten werden müssen.

Beispielsweise ändern die meisten x86-Ganzzahl-Additions- und Subtraktionsanweisungen das Flags-Register. Nach dem Durchführen eines Addierens oder Subtrahierens besteht die nächste Operation häufig darin, das Flags-Register auf Überlauf, Vorzeichenbit usw. zu überprüfen. Wenn danach ein weiteres Addierelement vorhanden ist, ist es sehr schwierig zu bestimmen, ob die Ausführung des zweiten Addierelements sicher ist bevor das Ergebnis der 1. Addition bekannt ist.

In einer RISC-Architektur würde der Befehl add die Eingabeoperanden und die Ausgaberegister angeben, und alles über die Operation würde nur unter Verwendung dieser Register erfolgen. Dies erleichtert das Entkoppeln von Add-Vorgängen, die nahe beieinander liegen, da kein Blooming-Flag-Register vorhanden ist, das alles zum Ausrichten und Ausführen einer einzelnen Datei zwingt.

Der DEC Alpha AXP-Chip, ein RISC-Design im MIPS-Stil, war in den verfügbaren Anweisungen schmerzlich spartanisch, aber der Befehlssatz wurde entwickelt, um implizite Registerabhängigkeiten zwischen Befehlen zu vermeiden. Es gab kein hardwaredefiniertes Stapelregister. Es gab kein hardwaredefiniertes Flagsregister. Sogar der Anweisungszeiger war OS-definiert - wenn Sie zum Anrufer zurückkehren wollten, mussten Sie herausfinden, wie der Anrufer Ihnen mitteilen sollte, an welche Adresse Sie zurückkehren möchten. Dies wurde normalerweise durch die OS-Aufrufkonvention definiert. Auf dem x86 wird es jedoch durch die Chip-Hardware definiert.

Über 3 oder 4 Generationen von Alpha-AXP-Chip-Designs ging die Hardware von einer wörtlichen Implementierung des spartanischen Befehlssatzes mit 32 Int-Registern und 32 Float-Registern zu einer massiv außer Betrieb befindlichen Ausführungs-Engine mit 80 internen Registern, Registerumbenennung, über. Ergebnisweiterleitung (wobei das Ergebnis einer vorherigen Anweisung an eine spätere Anweisung weitergeleitet wird, die vom Wert abhängt) und alle möglichen wilden und verrückten Leistungssteigerungen. Und mit all diesen Schnickschnack war der AXP-Chip-Chip immer noch erheblich kleiner als der vergleichbare Pentium-Chip-Chip jener Zeit, und der AXP war um einiges schneller.

Derartige Performance-Impulse sind im x86-Stammbaum nicht zu sehen, da die Komplexität des x86-Befehlssatzes viele Arten von Ausführungsoptimierungen unerschwinglich, wenn nicht sogar unmöglich macht. Intels genialer Schachzug bestand darin, auf die Implementierung des x86-Befehlssatzes in Hardware zu verzichten - alle modernen x86-Chips sind eigentlich RISC-Kerne, die die x86-Befehle bis zu einem gewissen Grad interpretieren und in internen Mikrocode umsetzen, der die gesamte Semantik des ursprünglichen x86 beibehält Befehl, ermöglicht aber ein wenig von diesem RISC-Fehler und andere Optimierungen über den Mikrocode.

Ich habe viel x86-Assembler geschrieben und kann die Bequemlichkeit seiner CISC-Wurzeln voll einschätzen. Aber ich wusste nicht genau, wie kompliziert x86 war, bis ich einige Zeit damit verbracht habe, Alpha AXP Assembler zu schreiben. Ich war begeistert von der Einfachheit und Gleichmäßigkeit von AXP. Die Unterschiede sind enorm und tiefgreifend.

24
dthorpe

Die x86-Architektur stammt aus dem Design des 8008-Mikroprozessors und seiner Verwandten. Diese CPUs wurden in einer Zeit entwickelt, in der der Speicher langsam war, und wenn Sie dies auf dem CPU-Chip tun konnten, war es oft ein viel schneller. Der CPU-Speicherplatz war jedoch ebenfalls teuer. Diese beiden Gründe sind, warum es nur eine kleine Anzahl von Registern gibt, die tendenziell spezielle Zwecke haben, und einen komplizierten Befehlssatz mit allen möglichen Fallstricken und Einschränkungen.

Andere Prozessoren aus der gleichen Zeit (z. B. die 6502-Familie) weisen ähnliche Einschränkungen und Besonderheiten auf. Interessanterweise waren sowohl die 8008-Serie als auch die 6502-Serie als Embedded-Controller gedacht. Schon damals wurde erwartet, dass Embedded-Controller in Assembler programmiert werden und in vielerlei Hinsicht eher dem Assembly-Programmierer als dem Compiler-Schreiber vorbehalten sind. (Sehen Sie sich den VAX-Chip an, um zu erfahren, was passiert, wenn Sie den Compiler-Schreibvorgang ausführen.) Die Designer haben nicht erwartet, dass sie Allzweck-Computerplattformen werden. Dafür waren Dinge wie die Vorgänger der POWER-Architektur da. Die Heimcomputer-Revolution hat das natürlich geändert.

19
staticsan

Ich habe hier ein paar zusätzliche Aspekte:

Betrachten Sie die Operation "a = b/c" x86 würde dies als implementieren

  mov eax,b
  xor edx,edx
  div dword ptr c
  mov a,eax

Als zusätzlichen Bonus des div-Befehls enthält edx den Rest.

Ein RISC-Prozessor würde zuerst das Laden der Adressen von b und c, das Laden von b und c aus dem Speicher in die Register, das Aufteilen und Laden der Adresse von a und das Speichern des Ergebnisses erfordern. Dst, src-Syntax:

  mov r5,addr b
  mov r5,[r5]
  mov r6,addr c
  mov r6,[r6]
  div r7,r5,r6
  mov r5,addr a
  mov [r5],r7

Hier gibt es normalerweise keinen Rest.

Wenn Variablen durch Zeiger geladen werden sollen, können beide Sequenzen länger werden, obwohl dies für das RISC weniger wahrscheinlich ist, da möglicherweise bereits ein oder mehrere Zeiger in ein anderes Register geladen sind. x86 hat weniger Register, daher ist die Wahrscheinlichkeit, dass sich der Zeiger in einem von ihnen befindet, geringer.

Vor-und Nachteile:

Die RISC-Anweisungen können mit Umgebungscode gemischt werden, um die Befehlsplanung zu verbessern. Dies ist bei x86 weniger wahrscheinlich. Stattdessen funktioniert dies (je nach Sequenz mehr oder weniger gut) in der CPU selbst. Die obige RISC-Sequenz ist in der Regel 28 Byte lang (7 Befehle mit jeweils 32 Bit/4 Byte Breite) in einer 32-Bit-Architektur. Dies bewirkt, dass der Off-Chip-Speicher beim Abrufen der Anweisungen mehr funktioniert (sieben Abrufe). Die dichtere x86-Sequenz enthält weniger Befehle, und obwohl ihre Breite variiert, sehen Sie dort wahrscheinlich auch einen Durchschnitt von 4 Bytes/Befehl. Selbst wenn Sie Anweisungs-Caches haben, um diese sieben Abrufe zu beschleunigen, bedeutet dies, dass Sie ein Defizit von drei gegenüber dem x86 an anderer Stelle ausgleichen müssen.

Die x86-Architektur mit weniger zu speichernden/wiederherzustellenden Registern bedeutet, dass wahrscheinlich Thread-Schalter ausgeführt und Interrupts schneller verarbeitet werden als RISC. Mehr Register zum Speichern und Wiederherstellen erfordern mehr temporären RAM Stapelspeicher für Interrupts und mehr permanenten Stapelspeicher zum Speichern von Thread-Zuständen. Diese Aspekte sollten x86 zu einem besseren Kandidaten für die Ausführung von reinem RTOS machen.

Persönlicher finde ich es schwieriger, RISC Assembly zu schreiben als x86. Ich löse dies, indem ich die RISC-Routine in C schreibe und den generierten Code kompiliere und ändere. Dies ist vom Standpunkt der Code-Produktion effizienter und vom Standpunkt der Ausführung wahrscheinlich weniger effizient. Alle diese 32 Register, um den Überblick zu behalten. Bei x86 ist es umgekehrt: 6-8 Register mit "echten" Namen machen das Problem leichter handhabbar und sorgen für mehr Vertrauen, dass der erzeugte Code wie erwartet funktioniert.

Hässlich? Das liegt im Auge des Betrachters. Ich bevorzuge "anders".

12
Olof Forshell

Ich denke, diese Frage hat eine falsche Annahme. Es sind hauptsächlich RISC-besessene Wissenschaftler, die x86 als hässlich bezeichnen. In Wirklichkeit kann der x86 ISA in einem einzigen Befehl 5-6 Anweisungen für RISC-ISAs ausführen. RISC-Fans könnten dagegen vorgehen, dass moderne x86-CPUs diese "komplexen" Anweisungen in Mikrobereiche aufteilen ; jedoch:

  1. In vielen Fällen stimmt das nur teilweise oder gar nicht. Die nützlichsten "komplexen" Anweisungen in x86 sind Dinge wie mov %eax, 0x1c(%esp,%edi,4), d. H. Adressierungsmodi, und diese sind nicht aufgeschlüsselt.
  2. Was auf modernen Maschinen oft wichtiger ist, ist nicht die Anzahl der Zyklen (da die meisten Aufgaben nicht an die CPU gebunden sind), sondern die Auswirkung des Befehls-Cache auf den Code. 5-6 Befehle mit fester Größe (normalerweise 32 Bit) wirken sich auf den Cache viel mehr aus als ein komplexer Befehl, der selten mehr als 5 Byte umfasst.

x86 hat wirklich alle guten Aspekte von RISC vor 10-15 Jahren in sich aufgenommen, und die verbleibenden Eigenschaften von RISC (eigentlich die definierende - der minimale Befehlssatz ) sind schädlich und unerwünscht.

Abgesehen von den Kosten und der Komplexität der Herstellung von CPUs und deren Energiebedarf ist x86 der beste ISA. Jeder, der Ihnen etwas anderes sagt, lässt zu, dass Ideologie oder Agenda der Argumentation im Wege stehen.

Auf der anderen Seite ist ARM oder MIPS wahrscheinlich sinnvoller, wenn Sie auf eingebettete Geräte abzielen, bei denen die Kosten der CPU zählen, oder auf eingebettete/mobile Geräte, bei denen der Energieverbrauch im Vordergrund steht Beachten Sie jedoch, dass Sie sich immer noch mit dem zusätzlichen RAM und der Binärgröße befassen müssen, die erforderlich sind, um Code zu verarbeiten, der leicht 3-4-mal größer ist, und Sie werden nicht in der Lage sein, an die Leistung heranzukommen Sie werden darauf laufen.

9
R..

x86 Assembler-Sprache ist nicht so schlecht. Wenn Sie an den Maschinencode gelangen, wird er wirklich hässlich. Anweisungscodierungen, Adressierungsmodi usw. sind viel komplizierter als bei den meisten RISC-CPUs. Aus Gründen der Abwärtskompatibilität wurde ein zusätzlicher Spaß eingebaut - Dinge, die nur dann funktionieren, wenn sich der Prozessor in einem bestimmten Zustand befindet.

In 16-Bit-Modi kann die Adressierung beispielsweise geradezu bizarr erscheinen. Es gibt einen Adressierungsmodus für [BX+SI], aber keine für [AX+BX]. Solche Dinge erschweren in der Regel die Registernutzung, da Sie sicherstellen müssen, dass sich Ihr Wert in einem Register befindet, das Sie nach Bedarf verwenden können.

(Glücklicherweise ist der 32-Bit-Modus viel vernünftiger (wenn auch manchmal etwas seltsam - zum Beispiel Segmentierung), und der 16-Bit-x86-Code ist außerhalb von Bootloadern und einigen eingebetteten Umgebungen größtenteils irrelevant.)

Es gibt auch die Reste der alten Zeiten, als Intel versuchte, x86 zum ultimativen Prozessor zu machen. Anweisungen, die ein paar Bytes lang waren und Aufgaben ausführten, die eigentlich niemand mehr erledigte, weil sie offen gesagt zu langsam oder kompliziert waren. Die ENTER- und LOOP-Anweisungen , für zwei Beispiele - beachten Sie, dass der C-Stack-Frame-Code für die meisten Compiler wie "Push ebp; mov ebp, esp" und nicht "enter" lautet.

7
cHao

Ich bin kein Experte, aber es scheint, dass viele der Gründe, warum die Leute es nicht mögen, darin liegen, dass es eine gute Leistung erbringt. Vor einigen Jahren galten Register (anstelle eines Stapels), Registerrahmen usw. als nützliche Lösungen, um die Architektur für den Menschen einfacher erscheinen zu lassen. Heutzutage ist jedoch die Cache-Leistung von Bedeutung, und dank der Wörter variabler Länge von x86 können mehr Anweisungen im Cache gespeichert werden. Die "Anweisungsdecodierung", auf die Gegner, wie ich glaube, einmal hingewiesen haben, die Hälfte des Chips in Anspruch genommen haben, ist bei weitem nicht mehr so.

Ich denke, Parallelität ist heutzutage einer der wichtigsten Faktoren - zumindest für Algorithmen, die bereits schnell genug laufen, um verwendbar zu sein. Durch das Ausdrücken einer hohen Parallelität in der Software kann die Hardware Speicherlatenzen amortisieren (oder häufig vollständig verbergen). Natürlich liegt die Zukunft der Architektur in einer Art Quantencomputer.

Ich habe von nVidia gehört, dass einer der Fehler von Intel darin bestand, dass die Binärformate nahe an der Hardware gehalten wurden. Der PTX von CUDA führt einige Berechnungen zur schnellen Registerverwendung durch (Grafikfärbung), sodass nVidia anstelle einer Stapelmaschine eine Registermaschine verwenden kann, aber immer noch über einen Aktualisierungspfad verfügt, der nicht die gesamte alte Software zerstört.

3
gatoatigrado

Ich denke, Sie werden einen Teil der Antwort erhalten, wenn Sie jemals versuchen, einen Compiler zu schreiben, der auf x86 abzielt, oder wenn Sie einen x86-Maschinenemulator schreiben, oder wenn Sie versuchen, ISA in einem Hardware-Design.

Obwohl ich verstehe, ist das "x86 hässlich!" Argumente, ich denke immer noch, es ist mehr Spaß x86-Assembly zu schreiben als MIPS (zum Beispiel) - letzteres ist einfach langweilig. Es sollte für Compiler immer nett sein und nicht für Menschen. Ich bin nicht sicher, ob ein Chip Compiler-Autoren feindlicher sein könnte, wenn er es versucht ...

Das Hässlichste für mich ist die Funktionsweise der (Real-Modus-) Segmentierung: Jede physikalische Adresse hat 4096 Segmente: Offset-Aliase. Wann hast du das letzte Mal brauchst? Es wäre so viel einfacher gewesen, wenn der Segmentteil streng höherwertige Bits einer 32-Bit-Adresse wäre.

3

Neben den Gründen haben die Leute bereits erwähnt:

  • x86-16 hatte ein ziemlich seltsames Speicheradressierungsschema , das es ermöglichte, einen einzelnen Speicherort auf bis zu 4096 verschiedene Arten zu adressieren, begrenzt RAM auf 1 MB, und erzwungen Die Umstellung auf 32-Bit machte diese Funktion zum Glück überflüssig, aber x86-Chips enthalten immer noch eine Vielzahl von Segmentregistern.
  • Obwohl es sich nicht um einen Fehler von x86 per se handelte, waren x86-Aufrufkonventionen nicht so standardisiert wie MIPS (hauptsächlich, weil MS-DOS keine Compiler enthielt) ) und hinterlässt uns das Durcheinander von __cdecl, __stdcall, __fastcall, etc.
2
dan04
  1. x86 verfügt über einen sehr, sehr begrenzten Satz von Allzweckregistern

  2. es fördert einen sehr ineffizienten Entwicklungsstil auf der untersten Ebene (CISC-Hölle) anstelle einer effizienten Lade-/Speichermethode

  3. Intel traf die schreckliche Entscheidung, das völlig blöde Modell der Segment-/Offset-Speicheradressierung einzuführen, um mit (zu diesem Zeitpunkt bereits!) Veralteter Technologie kompatibel zu bleiben

  4. Zu einer Zeit, in der alle auf 32-Bit umgingen, hielt der x86 die Mainstream-PC-Welt mit mageren 16-Bit-Prozessoren zurück (die meisten davon - der 8088 - sogar nur mit externen 8-Bit-Datenpfaden, was noch beängstigender ist!)


Für mich (und ich bin ein DOS-Veteran, der jede Generation von PCs aus Entwicklersicht gesehen hat!) War Punkt 3 das Schlimmste.

Stellen Sie sich die folgende Situation vor, die wir in den frühen 90ern hatten (Mainstream!):

a) Ein Betriebssystem mit verrückten Einschränkungen aus älteren Gründen (640 KB leicht zugänglicher RAM) - DOS

b) Eine Betriebssystemerweiterung (Windows), die mehr RAM leisten konnte, aber in Sachen Spiele usw. nur begrenzt zur Verfügung stand und nicht die stabilste auf der Welt war (zum Glück änderte sich dies später, aber ich spreche hier von den frühen 90ern

c) Die meiste Software war noch DOS und wir mussten häufig Bootdisketten für spezielle Software erstellen, da es diese EMM386.exe gab, die einigen Programmen gefiel, anderen haßten (insbesondere Gamern - und ich war zu dieser Zeit ein AVID-Gamer - weiß was ich rede hier)

d) Wir waren auf MCGA 320x200x8 Bits beschränkt (ok, es gab ein bisschen mehr mit speziellen Tricks, 360x480x8 war möglich, aber nur ohne Laufzeitbibliotheksunterstützung), alles andere war chaotisch und schrecklich ("VESA" - lol)

e) In Bezug auf die Hardware hatten wir jedoch 32-Bit-Computer mit einigen Megabyte RAM und VGA-Karten mit einer Unterstützung von bis zu 1024x768

Grund für diese schlechte Situation?

Eine einfache Designentscheidung von Intel. Maschinenbefehlslevel (NICHT Binärlevel!) Kompatibilität zu etwas, das bereits im Sterben lag, ich glaube es war der 8085. Die anderen, scheinbar nicht verwandten Probleme (Grafikmodi, etc ...) waren aus technischen Gründen und wegen der sehr engen Grenzen verbunden Gleichgesinnte Architektur brachte die x86-Plattform mit sich.

Heute ist die Situation anders, aber fragen Sie jeden Assembler-Entwickler oder jeden, der Compiler-Backends für den x86 erstellt. Die wahnsinnig geringe Anzahl von Allzweckregistern ist nichts anderes als ein schrecklicher Leistungskiller.

0
Turing Complete