Wie kann windows 11 ARM eigentlich x86 Programme ausführen?
Das x86, ARM programme emulieren kann verstehe ich ja, da dies ein leistungsstärkere Architektur ist, diemit einer schwächeren Architektur Software gut auskommen sollte.
Aber Windows 11 ARM64 kann auch x64 .exe Dateien ausführen...
Wie ist das eigentlich möglich?
Sind x64 (cisc) Anwendungen nicht viel aufwendiger und komplexer als eine Leistungsschwächere arm64 (risc) Anwendung?
cisc Unterstützt doch mehrere Befehlszeichen pro Befehlssatz, während risc (ARM) nur einen Befehlszeichen pro Befehlssatz unterstüzt?
Wenn nun also eine ARM64 Software auf x64 ausgeführt wird, kann das ja sehr leicht funktionieren, da der (cisc) Prozessor mit dem einen Befehlzeichen pro Satz locker auskommt, da er theoretisch auch mehr könnte....
Wenn nun aber eine x64 Software auf einem ARM64 Prozessor ausgeführt wird, wie soll der (risc) Prozessor denn bitte mehrere Befehlszeichen pro Befehlssatz ausführen können?
Und wie stark wirkt sich das auf die Performance aus,
Wenn ich nun eine x64 Anwendung auf arm64 System ausführe...
Und wie stark im verhältnis wirkt es sich auf die Leistung aus, wenn ich eine arm64 Anwendung auf einem x64 System ausführe?
2 Antworten
RISC ist nicht "schwach"!
Während ein CISC sehr viele Schaltkreise braucht und zwischen denen sehr aufwändig umschalten kann, hat ein RISC wenige Schaltkreise die nicht großartig umgeschaltet werden müssen.
Dadurch braucht ein RISC viel weniger Strom und kann auch gleichzeitig mit einem höheren Takt gefahren werden. Dazu braucht er pro Befehl auch viel weniger Takte.
Da die meisten Programmanweisungen selten gebraucht werden, laufen also die oft benötigten die im RISC auch vorhanden sind viel schneller, für alles andere muss man dann mehrere Befehle verwenden. Im Durchschnitt hat man dann immer noch viel Strom und Zeit gespart.
Dazu kommt, dass moderne RISC Prozessoren an moderne Programmiersprachen angepasst sind und mehr Register haben. Die Programmiersprache kann dann Variablen, pointer und anderes dort aufheben während der klassische CISC diese immer wieder bei jedem Programmschritt zwischen RAM und den wenigen Prozessorregisterm hin und her kopieren muss.
So braucht ein AVR Microcontroller trotz RISC viel weniger Programmcode (unnötiges kopieren braucht auch Befehle) als ein CISC oder alter RISC.
Bei der Emulation werden ja Prozessorregister und was die Befehle damit machen simuliert. Also können die Befehle so oder so nicht 1:1 ausgeführt werden sondern müssen durch eine ganze Anzahl von Befehlen simuliert werden. Dann braucht ein RISC halt mehr Befehle um den anderen Prozessor zu simulieren.
Der Compiler optimiert ein Programm für den eingestellten Prozessortyp. So können die gleichen "Befehle" in der Hochsprache ganz unterschiedlichen Code erzeugen der eben auf diese CPU angepasst ist und deren Stärken nutzen kann.
So hat der x86 das normale Arbeitsregister (Klassisch Akku genannt, neudeutsch Working Register) und 4 Hilfsregister (Klassisch X-Register). Je nach Befehl müssen die dann entsprechend mit Daten gefüttert werden die sich der Befehl dann dort holt und verarbeitet. So kommt es oft vor, dass man das Ergebnis einer operation aus dem Akku wieder in das X Register kopieren muss um damit weiter arbeiten zu können.
Mit dem ARM64 bin ich nicht so vertraut, aber ich bin mir relativ sicher, dass der wie der AVR ganz viele Register hat die man in gewissen Grenzen beliebig benutzen kann. So kann man das Ergebnis einer Operation im Register lassen und der nächsten Operation nur sagen, dass die dieses als Eingangswert nehmen soll. So entfällt das kopieren.
Dazu kann eine Hochsprache wichtige Variablen in diesen Registern parken und bearbeiten ohne die immer wieder ins RAM sichern zu müssen. So können Werte und Pointer an Unterprogramme weiter gegeben werden und die müssen oft noch nicht mal im RAM gesichert werden, die können direkt in der CPU bleiben. Neben Variablen die der Programmierer anlegt braucht die Hochsprache auch viele Unsichtbare Variablen um den Programmablauf zu steuern. Auf einem CISC kostet das irre viel zeit die imemr wieder her zu holen, zu aktualisieren und wieder weg zu sichern. Beim AVR (und so weit ich weiß auch beim ARM64) entfällt die kopiererei, diese Variablen können dann "fliegend" angepasst und ausgewertet werden ohne lange auf RAM warten zu müssen.
Compiliert man also für den "falschen" Prozessor, entfallen viele dieser Optimierungen und dann muss der Emulator auch noch Dinge die der Prozessor nicht kann aufwändig simulieren.
Der ARM64 kann x86 Programme recht leicht emulieren da er sozusagen die simulierten Prozessorregister mit leichtigkeit in seinen eigenen Registern halten kann. Umgekehrt muss der x86 dauernd die vielen Register im RAM sichern und viel hin und her kopieren.
Im Prinzip und praktisch: Gar nicht.
Du bräuchtest dafür einen Emulator. Allerdings sind ARM-Geräte für eine x86er-Emulation zu Schwach auf der Brust.
Tatsache ist ja, das es ja gehen muss.
Sonst würde Windows 11 ARM keine x64 .exe Dateien ausführen können und Sonst würde sowas wie Bluestacks nicht funktionieren können...
Daher auch die Frage.
Die Dateiendung .exe sagt bezüglich der Chip-Konstruktion, auf der sie läuft, erst mal gar nichts aus.
Wenn es funktionieren würde, dann würdest Du nicht fragen.
Anyway: Es ändert nix an der Antwort: Emulation.
Das die Dateiendung nichts zu sagen hat und mehr Deko als tatsächliche Funktion ist weiß ich selber auch.
Auf Linux gibt es da z.b. keine einheitliche Dateiendung für Ausführbare Dateien. Im Fall von Unity Games wäre es: ".x86_64" als Endung. während andere Programme wieder was anderes oder auch gar nichts haben können.
Es funktioniert doch aber und ich FRAGE hier, wie genau das funktioniert?
Windows 11 ARM kann x64 und arm64 Dateien ausführen, während Windows 11 x64 nur die eigene Architectur ausführen kann.
Ansonsten wurde die ursprüngliche Frage bereits sehr gut schon von Commodore64 beantwortet.
Das die Dateiendung nichts zu sagen hat und mehr Deko als tatsächliche Funktion ist weiß ich selber auch.
Ja anscheinend erst nach meinem Hinweis - warum würdest Du dann sonst diesen Punkt überhaupt auf den Tisch bringen? 🤷♂️
Auf Linux gibt es da
Windows ist nicht Linux. 🤷♂️
Ansonsten wurde die ursprüngliche Frage bereits sehr gut schon von Commodore64 beantwortet.
Ist ja O.K.
Deine Reaktion darauf zeigt aber nicht, dass Du nicht wirklich verstanden hast, was der Punkt ist. 🤷♂️
Da der Bums hier aber Mimimi-Niveau erreicht hat verabschiede ich mich nun final.
Die Emulation funktioniert prinzipiell und praktisch auf Windows 11. Mit Leistungseinbußen darf man rechnen.
Wenn ich nun ein ARM64 Prozessor habe auf dem Windows 11 ARM läuft, was für auswirkungen hat es, wenn ich ein x64 Computerspiel nun auf dem Windows ARM64 ausführe im verhältnis zu dem selben Computerspiel, das jedoch für arm64 kompiliert wurde?
(Diese situation habe ich gerade da ich ein Spiel ohne große änderung sowohl für x64 als auch arm64 für Windows exportieren kann.)