Wie unterscheidet sich die ARM-Architektur von x86? [geschlossen]


192

Ist die x86-Architektur speziell für die Verwendung mit einer Tastatur konzipiert, während ARM erwartet, mobil zu sein? Was sind die Hauptunterschiede zwischen den beiden?


37
Sofern der x86 keinen ps / 2-Anschluss hat, von dem ich nichts weiß, ist er nicht mehr für Tastaturen
geeignet

6
Ich denke, die Tastatur bezieht sich auf eine typische PC-Rolle im Gegensatz zum physischen Gerät.
Kunstloser Lärm

24
Das x86 wurde nicht entwickelt; Es entwickelte sich auf einer Insel mit einem seltsamen Vogel, der alles aß, was versuchte, darauf zu beten. Es sieht jetzt seltsamer aus als ein Schnabeltier mit Entenschnabel und würde es nicht gut machen, wenn ein Schiff voller neuer Tiere vorbeikäme.
Strg-Alt-Delor

5
@richard - leider ist dies die historisch genaueste Beschreibung von x86, die ich je gesehen habe. Es sagt ziemlich viel über die Branche aus.
Leeor

6
@ Leeor Tut mir leid, dass ich in meinem Kommentar einen kleinen Fehler gemacht habe. Ich sagte, dass der Vogel Raubtiere des x86 gefressen hat, wo er, da er sie nicht gefressen hat, auf ihnen saß. Bemerkenswert ist auch, dass die weichen Federn des Vogels so sehr sehr sehr ordentlich waren.
Strg-Alt-Delor

Antworten:


304

ARMist eine RISC- Architektur (Reduced Instruction Set Computing), während x86es sich um eine CISC- Architektur (Complex Instruction Set Computing) handelt.

Der Hauptunterschied zwischen diesen Aspekten besteht darin, dass ARM-Befehle nur in Registern mit wenigen Anweisungen zum Laden und Speichern von Daten aus / in den Speicher ausgeführt werden, während x86 auch direkt im Speicher ausgeführt werden kann. Bis v8 war ARM eine native 32-Bit-Architektur, die Vier-Byte-Operationen gegenüber anderen bevorzugte.

ARM ist also eine einfachere Architektur, die zu einer kleinen Siliziumfläche und vielen Energiesparfunktionen führt, während x86 sowohl hinsichtlich des Stromverbrauchs als auch der Produktion zu einem Energietier wird.

Informationen zu " Ist die x86-Architektur speziell für die Verwendung mit einer Tastatur konzipiert, während ARM erwartet, mobil zu sein? ". x86ist nicht speziell für die Arbeit mit einer Tastatur konzipiert, auch nicht ARMfür Handys. Aufgrund der zentralen Architekturoptionen verfügt x86 jedoch auch über Anweisungen, mit denen direkt gearbeitet werden kann, IOwährend ARM dies nicht tut. Mit speziellen E / A-Bussen wie USBs verschwindet jedoch auch der Bedarf an solchen Funktionen.

Wenn Sie ein Dokument zum Zitieren benötigen, finden Sie in den Programmieranleitungen der Cortex-A-Serie (4.0) Informationen zu Unterschieden zwischen RISC- und CISC-Architekturen:

Ein ARM-Prozessor ist ein RISC-Prozessor (Reduced Instruction Set Computer).

CISC-Prozessoren (Complex Instruction Set Computer) verfügen wie der x86 über einen umfangreichen Befehlssatz, mit dem komplexe Aufgaben mit einem einzigen Befehl ausgeführt werden können. Solche Prozessoren verfügen häufig über erhebliche Mengen an interner Logik, die Maschinenbefehle in Sequenzen interner Operationen (Mikrocode) decodieren.

Im Gegensatz dazu weisen RISC-Architekturen eine geringere Anzahl allgemeinerer Befehle auf, die möglicherweise mit erheblich weniger Transistoren ausgeführt werden, wodurch das Silizium billiger und energieeffizienter wird. Wie andere RISC-Architekturen verfügen ARM-Kerne über eine große Anzahl von Allzweckregistern, und viele Befehle werden in einem einzigen Zyklus ausgeführt. Es verfügt über einfache Adressierungsmodi, in denen alle Lade- / Speicheradressen aus Registerinhalten und Anweisungsfeldern ermittelt werden können.

Das Unternehmen ARM bietet außerdem einen Artikel mit dem Titel " Architektur, Prozessoren und Geräteentwicklung" an, in dem beschrieben wird, wie diese Begriffe für das Geschäft gelten.

Ein Beispiel für den Vergleich der Befehlssatzarchitektur:

Wenn Sie beispielsweise in Ihrer Anwendung einen byteweisen Speichervergleichsblock benötigen (vom Compiler generiert, Details übersprungen), sieht dies möglicherweise so aus x86

repe cmpsb         /* repeat while equal compare string bytewise */

während in ARMkürzester Form aussehen könnte (ohne Fehlerprüfung etc.)

top:
ldrb r2, [r0, #1]! /* load a byte from address in r0 into r2, increment r0 after */
ldrb r3, [r1, #1]! /* load a byte from address in r1 into r3, increment r1 after */
subs r2, r3, r2    /* subtract r2 from r3 and put result into r2      */
beq  top           /* branch(/jump) if result is zero                 */

Dies sollte Ihnen einen Hinweis geben, wie sich die Komplexität von RISC- und CISC-Befehlssätzen unterscheidet.


9
ARMv8-A verfügt über eine 64-Bit-Architektur namens AArch64.
Cyrias

9
Obwohl der x86 einige sehr mächtige Anweisungen hat, kann der Arm ihn dennoch in einem Kampf schlagen (wenn beide die gleiche Taktrate haben). Dies liegt zum Teil daran, dass der Arm über einen guten Registersatz verfügt, bei dem der x86 die Hälfte seiner Zeit damit verbringt, Daten in seinen begrenzten Registersatz hinein und aus diesem heraus zu bewegen (dies gilt weniger für x86-64, da er mehr Register hat ). Und teilweise, weil die Einfachheit des Arms Platz für einen größeren Cache lässt und alle Anweisungen an Bedingungen geknüpft sind (wodurch weniger Cache-Fehler auftreten). Durch die Mehrfachanweisung von arm's move (die einzige Nicht-RISC-Anweisung) können Daten schnell verschoben werden.
Strg-Alt-Delor

4
Ich könnte ARM-Code schneller schreiben, obwohl größer, indem ich mehr Register verwende. Wenn ich mir diese Implementierung anschaue, benötigt der x86 5 + 9 × N Takte, der ARM 4 × N Takte (beide Abbildungen gelten für keine Cache-Fehler). Das x86-Ergebnis für Befehlsbytes in diesem Beispiel ist besser: x86 = 2 Bytes, arm = 16 Bytes. ARM schneidet bei dieser Metrik in realistischeren Tests viel besser ab, z. B. beim Verlassen der Schleife r2 werden Informationen darüber angezeigt, ob Zeichenfolgen gleich sind / welche größer sind, ebenso wie Bedingungscodes. Der Arm kann andere Anweisungen ausführen, bevor die Bedingungscodes überprüft werden. Der Arm muss beim Überprüfen der Bedingungscodes nicht verzweigen.
Strg-Alt-Delor

2
@JeremyFelix Es sieht so aus: stackoverflow.com/questions/13106297/… Es gibt verschiedene Pipes für verschiedene Arten von Anweisungen, auch wenn es doppelte gibt. Die CPU unterteilt Befehle in Mikrobefehle, und diese können parallel zwischen den Pipelines ausgeführt werden.
Auselen

2
Sie sagen: "Während x86 auch direkt mit Speicher arbeiten kann." Für das x86 (vor x86-64) gibt es jedoch so wenige Register, dass es kein "auch" gab. Sie mussten alles im Speicher speichern. Etwa die Hälfte der Anweisungen in einem Programm, in dem nur Dinge verschoben werden sollen. Während in ARM nur sehr wenige Anweisungen zum Verschieben von Daten erforderlich sind.
Strg-Alt-Delor

93

Weder hat etwas Spezielles für Tastatur oder Handy, außer der Tatsache, dass ARM seit Jahren einen ziemlich erheblichen Vorteil in Bezug auf den Stromverbrauch hat, was es für alle Arten von batteriebetriebenen Geräten attraktiv machte.

Was die tatsächlichen Unterschiede angeht: ARM verfügt über mehr Register, unterstützt die Prädikation für die meisten Anweisungen, lange bevor Intel sie hinzufügte, und hat seit langem alle möglichen Techniken (nennen Sie sie "Tricks", wenn Sie es vorziehen) integriert, um fast überall Strom zu sparen.

Es gibt auch einen erheblichen Unterschied darin, wie die beiden Anweisungen codieren. Intel verwendet eine ziemlich komplexe Codierung mit variabler Länge, bei der ein Befehl zwischen 1 und 15 Byte belegen kann. Dies ermöglicht es, dass Programme recht klein sind, macht jedoch das Dekodieren von Befehlen relativ schwierig (wie in: Das parallele Dekodieren von Befehlen ist eher ein Albtraum).

ARM verfügt über zwei verschiedene Befehlskodierungsmodi: ARM und THUMB. Im ARM-Modus erhalten Sie Zugriff auf alle Anweisungen, und die Codierung ist äußerst einfach und schnell zu decodieren. Leider ist der ARM-Modus-Code in der Regel ziemlich groß, sodass ein Programm häufig etwa doppelt so viel Speicher belegt wie Intel-Code. Der Daumenmodus versucht dies zu mildern. Es verwendet immer noch eine recht reguläre Befehlskodierung, reduziert jedoch die meisten Befehle von 32 Bit auf 16 Bit, z. B. durch Verringern der Anzahl der Register, Eliminieren von Prädikationen aus den meisten Befehlen und Verringern des Bereichs von Verzweigungen. Zumindest meiner Erfahrung nach gibt dies normalerweise immer noch nicht ganz nachDie Codierung ist so dicht wie x86-Code, aber sie ist ziemlich eng und die Decodierung ist immer noch recht einfach und unkompliziert. Eine geringere Codedichte bedeutet, dass Sie im Allgemeinen mindestens etwas mehr Speicher und (im Allgemeinen ernsthafter) einen größeren Cache benötigen, um eine gleichwertige Leistung zu erzielen.

Zu einer Zeit legte Intel viel mehr Wert auf Geschwindigkeit als auf Stromverbrauch. Sie begannen, den Stromverbrauch hauptsächlich im Zusammenhang mit Laptops zu betonen. Für Laptops lag ihr typisches Leistungsziel in der Größenordnung von 6 Watt für einen relativ kleinen Laptop. In jüngerer Zeit ( viel in jüngerer Zeit) haben sie begonnen, auf mobile Geräte (Telefone, Tablets usw.) abzuzielen. Für diesen Markt sehen sie höchstens ein paar Watt oder so. Sie scheinen darin ziemlich gut abzuschneiden, obwohl sich ihr Ansatz wesentlich von dem von ARM unterscheidet und die Herstellungstechnologie betont, bei der ARM hauptsächlich die Mikroarchitektur betont hat (nicht überraschend, wenn man bedenkt, dass ARM Designs verkauft und die Herstellung anderen überlässt).

Je nach Situation ist der Energieverbrauch einer CPU jedoch häufig wichtiger als der Stromverbrauch. Zumindest wenn ich die Begriffe verwende, bezieht sich der Stromverbrauch auf den (mehr oder weniger) sofortigen Stromverbrauch. Der Energieverbrauch normalisiert sich jedoch in Bezug auf die Geschwindigkeit. Wenn also beispielsweise CPU A 2 Sekunden lang 1 Watt verbraucht, um einen Job auszuführen, und CPU B 1 Sekunde lang 2 Watt verbraucht, um denselben Job auszuführen, verbrauchen beide CPUs dieselbe Gesamtmenge Energie (zwei Wattsekunden), um diesen Job zu erledigen - aber mit CPU B erhalten Sie doppelt so schnelle Ergebnisse.

ARM-Prozessoren schneiden in Bezug auf den Stromverbrauch sehr gut ab. Wenn Sie also etwas benötigen, das die "Präsenz" eines Prozessors fast ständig benötigt, aber nicht wirklich viel Arbeit leistet, können sie ziemlich gut funktionieren. Wenn Sie beispielsweise Videokonferenzen durchführen, erfassen Sie einige Millisekunden Daten, komprimieren sie, senden sie, empfangen Daten von anderen, dekomprimieren sie, spielen sie ab und wiederholen sie. Selbst ein sehr schneller Prozessor kann nicht viel Zeit mit Schlafen verbringen. Für solche Aufgaben ist ARM also sehr gut geeignet.

Die Prozessoren von Intel (insbesondere die Atom-Prozessoren, die eigentlich für Anwendungen mit geringem Stromverbrauch vorgesehen sind) sind hinsichtlich des Energieverbrauchs äußerst wettbewerbsfähig. Während sie fast ihre volle Geschwindigkeit erreichen, verbrauchen sie mehr Strom als die meisten ARM-Prozessoren - aber sie beenden die Arbeit auch schnell, sodass sie früher wieder einschlafen können. Infolgedessen können sie eine gute Akkulaufzeit mit einer guten Leistung kombinieren.

Wenn Sie also die beiden vergleichen, müssen Sie vorsichtig sein, was Sie messen, um sicherzugehen, dass es das widerspiegelt, was Sie ehrlich interessiert. ARM ist sehr gut im Stromverbrauch, aber je nach Situation interessiert Sie der Energieverbrauch möglicherweise mehr als der momentane Stromverbrauch.


deswegen ? RISC benötigt mehr RAM, während CISC einen Schwerpunkt auf kleinere Codegrößen legt und insgesamt weniger RAM verwendet als RISC
Waqar Naeem

Der Daumenmodus (variable Länge, die kurze Codierungen ermöglicht) ist kein Unterschied . So funktioniert x86 immer (aber mehr noch, mit einer Befehlslänge zwischen 1 und 15 Bytes, die viel schwieriger zu dekodieren ist als Thumb2). Der ARM-Modus (Codierung mit fester Breite und zerstörungsfreien Anweisungen mit 3 Operanden) ist der Unterschied zu x86!
Peter Cordes

Ein viel schnellerer Prozessor ist keine große Hilfe - Videokonferenzen könnten ein besseres Beispiel sein: Geringe Latenz bedeutet, dass Sie nicht einfach einen Decodierungsstoß in einen Puffer mit angemessener Größe ausführen und in einen tiefen oder mittleren Schlafzustand zurückkehren können . "Race to Sleep" ist ein Schlüsselkonzept für den Energieverbrauch bei einem festgelegten Rechenaufwand, da moderne CPUs im Leerlauf erhebliche Energieeinsparungen erzielen können (die Uhr wird gestoppt oder sogar Teile des Kerns heruntergefahren. In tieferen Schlafphasen auch Caches nach dem Zurückschreiben.) ... und das ist natürlich der Punkt, den Sie im nächsten Absatz ansprechen. >. <
Peter Cordes

@PeterCordes: Die Thumb-Modus-Codierung ähnelt nicht der x86-Codierung. Obwohl es nicht ganz so regelmäßig ist wie die ARM-Codierung, ist es dennoch ein ziemlich festes Format. Die Erhöhung der Dichte beruht hauptsächlich auf der Eliminierung von Bits, die bei der ARM-Codierung einfach selten verwendet werden. Beispielsweise sind praktisch alle ARM-Befehle bedingt, aber die Bedingungen werden nur zu einem relativ geringen Prozentsatz verwendet (daher sind die meisten nicht verzweigten THUMB-Befehle bedingungslos).
Jerry Coffin

@PeterCordes: Sie haben Recht: Videokonferenzen sind ein besseres Beispiel - ich habe das in bearbeitet. Danke.
Jerry Coffin

39

Zusätzlich zu Jerry Coffins erstem Absatz. Das heißt, das ARM-Design bietet einen geringeren Stromverbrauch.

Das Unternehmen ARMlizenziert nur die CPU-Technologie. Sie machen keine physischen Chips. Auf diese Weise können andere Unternehmen verschiedene Peripherietechnologien hinzufügen, die normalerweise als SOC oder System-on-Chip bezeichnet werden. Ob es sich bei dem Gerät um ein Tablet, ein Mobiltelefon oder ein Unterhaltungssystem im Auto handelt. Auf diese Weise können Chiphersteller den Rest des Chips an eine bestimmte Anwendung anpassen. Dies hat zusätzliche Vorteile,

  1. Niedrigere Boardkosten
  2. Geringere Leistung (Anmerkung 1)
  3. Einfachere Herstellung
  4. Kleinerer Formfaktor

ARMunterstützt SOC-Anbieter mit AMBA , sodass SOC-Implementierer Module von Drittanbietern von der Stange kaufen können; wie ein Ethernet-, Speicher- und Interrupt-Controller. Einige andere CPU-Plattformen wie MIPS unterstützen dies, aber MIPS ist nicht so leistungsbewusst.

All dies ist für ein handgehaltenes / batteriebetriebenes Design von Vorteil. Einige sind einfach rundum gut. Hat auch ARMeine Geschichte von batteriebetriebenen Geräten; Apple Newton , Psion Organisatoren . Die Infrastruktur der PDA-Software wurde von einigen Unternehmen genutzt, um Geräte vom Typ Smartphone zu erstellen . Mehr Erfolg hatten jedoch diejenigen, die die GUI für die Verwendung mit einem Smartphone neu erfunden haben .

Der Aufstieg der Open sourceWerkzeugsätze operating systemserleichterte auch die verschiedenen SOCSpäne. Eine geschlossene Organisation hätte Probleme beim Versuch, alle für den ARM verfügbaren Geräte zu unterstützen. Die beiden beliebtesten Mobilfunkplattformen Andriod und OSx / IOS basieren auf Linux- und FreeBSD-, Mach- und NetBSD-Betriebssystemen . Open Sourceunterstützt SOCAnbieter bei der Bereitstellung von Softwareunterstützung für ihre Chipsätze.

Hoffentlich ist es selbstverständlich , warum x86 für die Tastatur verwendet wird. Es verfügt über die Software und vor allem über Personen, die für die Verwendung dieser Software geschult sind. Netwinder ist ein ARMSystem, das ursprünglich für die Tastatur entwickelt wurde . Außerdem suchen Hersteller derzeit nach ARM64 für den Servermarkt. Strom / Wärme ist in Rechenzentren rund um die Uhr ein Problem.

Daher würde ich sagen, dass das Ökosystem , das um diese Chips herum wächst, genauso wichtig ist wie Funktionen wie ein geringer Stromverbrauch. ARMstrebt seit einiger Zeit (Mitte bis Ende der 1980er Jahre) nach Computern mit geringer Leistung und höherer Leistung und hat viele Leute an Bord.

Hinweis 1: Mehrere Chips benötigen Bustreiber, um bei bekannten Spannungen und Antrieben miteinander zu kommunizieren. Außerdem benötigen separate Chips normalerweise Unterstützungskondensatoren und andere Leistungskomponenten, die in einem SOC- System gemeinsam genutzt werden können.


22

Der ARM ist wie ein italienischer Sportwagen:

  • Gut ausbalanciert, gut abgestimmt, Motor. Bietet gute Beschleunigung und Höchstgeschwindigkeit.
  • Hervorragende Verfolgungsjagden, Bremsen und Federung. Kann schnell anhalten, kann Kurven fahren, ohne langsamer zu werden.

Der x86 ist wie ein amerikanisches Muscle-Car:

  • Großer Motor, große Kraftstoffpumpe. Bietet hervorragende Höchstgeschwindigkeit und Beschleunigung, verbraucht aber viel Kraftstoff.
  • Schreckliche Bremsen, müssen Sie einen Termin in Ihr Tagebuch setzen, wenn Sie langsamer werden möchten.
  • Schreckliche Lenkung, man muss langsamer fahren.

Zusammenfassend: Der x86 basiert auf einem Design von 1974 und ist in einer geraden Linie gut (verbraucht aber viel Kraftstoff). Der Arm verbraucht wenig Kraftstoff, verlangsamt sich nicht für Ecken (Äste).


Metapher vorbei, hier sind einige echte Unterschiede.

  • Arm hat mehr Register.
  • Arm hat nur wenige Spezialregister, x86 sind alle Spezialregister (also weniger bewegliches Material).
  • Arm hat nur wenige Speicherzugriffsbefehle, nur ein Lade- / Speicherregister.
  • Arm ist intern Harvard Architektur mein Design.
  • Arm ist einfach und schnell.
  • Armanweisungen sind architektonisch ein einzelner Zyklus (außer Laden / Speichern mehrerer).
  • Armanweisungen machen oft mehr als eine Sache (in einem einzigen Zyklus).
  • Wenn mehr als ein Arm-Befehl benötigt wird, wie z. B. der Looping-Speicher und das automatische Inkrementieren des x86, führt der Arm dies immer noch in weniger Taktzyklen aus.
  • Arm hat mehr bedingte Anweisungen.
  • Der Zweigprädiktor von Arm ist trivial einfach (wenn er bedingungslos oder rückwärts ist, dann wird ein Zweig angenommen, andernfalls wird kein Zweig angenommen) und bietet eine bessere Leistung als der sehr, sehr komplexe im x86 (hier ist nicht genügend Platz, um dies zu erklären, nicht dass ich es könnte ).
  • Arm verfügt über einen einfachen konsistenten Befehlssatz (Sie können ihn von Hand kompilieren und den Befehlssatz schnell erlernen).

7
Diese Analogie beruht auf der Tatsache, dass italienische Sportwagen in jedem Moment ausfallen, in dem sie sich befinden, während ARM-CPUs dies nicht tun, und dass dies zwar leicht möglich ist, Sie jedoch keine einzige ARM-CPU kaufen können, die Desktop-CPU-Geschwindigkeiten erreichen kann , geschweige denn Sockets und Mainboards, um sie
einzulegen

1
In Bezug auf die Leistung konkurriert es direkt mit einigen der größten / schnelleren Xeon-Prozessoren (z. B. E5-2690 v3), jedoch zu geringeren Kosten und Kosten. quora.com/…
Strg-Alt-Delor

1
Sicher für massiv parallele Workloads wie Datenbanken und E / A-Server. Für Single-Thread-Leistung hat niemand einen ARM-Kern entwickelt, der annähernd so groß wie x86 ist. Kein Grund, warum sie es nicht konnten, nur niemand hat es. Die "x86-Steuer" auf Strom- und Chipfläche ist nicht so hoch im Vergleich zu der Menge an Silizium, die für Maschinen außerhalb der Reihenfolge in Hochleistungs-CPU-Kernen verwendet wird. Es gibt sicherlich Warzen in x86, aber RISC hat einen Nachteil der Codedichte (was normalerweise nicht viel ausmacht, aber immer noch wichtig ist). Dies wird in den realworldtech.com- Foren wiederholt diskutiert.
Peter Cordes

1
@richard: Es gibt eine Menge Dinge, die du nicht "brauchst", aber das erhöht die Codedichte. Der Trick besteht darin, die Komplexität der Decodierung gegen die Codegröße / Anzahl der Anweisungen abzuwägen. Das Erhöhen der Breite eines Kerns außerhalb der Reihenfolge ist im Energieverbrauch extrem teuer, daher ist es wertvoll, mehr Arbeit in jeden Befehl zu packen. Eine geringfügige Erhöhung der Dekodierungskomplexität ist viel billiger. Moderne x86-CPUs können x86 bereits schnell dekodieren. (Nicht ganz schnell genug, um einen 4-breiten OOO-Kern von den Decodern anstelle von UOP-Cache oder Loop-Puffer zu speisen, und natürlich zu hohen Stromkosten.)
Peter Cordes

3
@ Evi1M4chine, es bricht auch an der Tatsache, dass ein italienischer Sportwagen enorm teuer ist, während ein America Muscle Car relativ billig ist. Und das Muscle-Car ist das, was es ist, weil es einfach ist, während so etwas wie ein Ferrari sehr, sehr kompliziert ist. Ganz im Gegenteil von CISC gegen RISC
Lorenzo Dematté

15

Die ARM-Architektur wurde ursprünglich für Acorn-PCs (siehe Acorn Archimedes , circa 1987, und RiscPC ) entwickelt, bei denen es sich ebenso um tastaturbasierte PCs handelte wie um x86-basierte IBM PC-Modelle. Erst spätere ARM-Implementierungen waren hauptsächlich auf das mobile und eingebettete Marktsegment ausgerichtet.

Ursprünglich konnten einfache RISC-CPUs mit ungefähr gleicher Leistung von viel kleineren Entwicklungsteams (siehe Berkeley RISC ) entworfen werden als diejenigen, die an der x86-Entwicklung bei Intel arbeiten.

Heutzutage verfügen die schnellsten ARM-Chips jedoch über sehr komplexe, von großen Entwicklungsteams entworfene, nicht in Auftrag gegebene Instruktionsversandeinheiten mit mehreren Ausgaben, und x86-Kerne verfügen möglicherweise über einen RISC-Kern, der von einer Instruktionsübersetzungseinheit gespeist wird.

Daher hängen aktuelle Unterschiede zwischen den beiden Architekturen eher mit den spezifischen Marktanforderungen der Produktnischen zusammen, auf die die Entwicklungsteams abzielen. (Zufällige Meinung: ARM macht wahrscheinlich mehr Lizenzgebühren für eingebettete Anwendungen, die tendenziell viel leistungsfähiger und kostenintensiver sind. Und Intel muss einen Leistungsvorteil bei PCs und Servern für ihre Gewinnspannen aufrechterhalten. Daher sehen Sie unterschiedliche Implementierungsoptimierungen.)


Es gibt immer noch massive architektonische Unterschiede. Intel hat jedoch einen wunderbaren Job gemacht und eine Menge Geld investiert, damit die schlecht strukturierte CPU sehr gut läuft (man fragt sich, was hätte getan werden können, wenn all diese Anstrengungen in eine gut strukturierte CPU gesteckt worden wären).
Strg-Alt-Delor
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.