@Hayda Ministral : Wie kommst du darauf ARM64EC hätte irgendwas mit p-code zu tun?
News ARM64EC für Windows 11: 64-Bit-Apps werden peu à peu fit für ARM, Office geht voran
Hayda Ministral
Banned
- Registriert
- Nov. 2017
- Beiträge
- 7.835
Das habe ich (sehr) frei aus der Beschreibung assoziiert.
bluedxca93
Commander
- Registriert
- Juli 2019
- Beiträge
- 2.059
Microsoft erfindet hoffentlich keine virtuelle Maschine als Zwischenebene das macht die Berechnung auf x64 und arm noch ineffizienter.
Hayda Ministral
Banned
- Registriert
- Nov. 2017
- Beiträge
- 7.835
p-Code war keine virtuelle Maschine...
KitKat::new()
Rear Admiral
- Registriert
- Okt. 2020
- Beiträge
- 5.869
Hayda Ministral
Banned
- Registriert
- Nov. 2017
- Beiträge
- 7.835
p-code wurde interpretiert, das ist der Teil wo meine Assoziation ein wenig arg überstrapaziert wird. Heutzutage würde man p-code vermutlich in die Zielmaschine übersetzen.
KitKat::new()
Rear Admiral
- Registriert
- Okt. 2020
- Beiträge
- 5.869
Also so in der Art wie das die x86 Emulatoren von MS und Apple das machen?Hayda Ministral schrieb:
Ansonsten verstehe ich nicht ganz was du sagen willst
Hab mich noch nicht großartig in das Thema eingarbeitet, aber soweit ich sehe geht es um folgendes:
TLDR:
Es geht schlicht darum binären x64 und binären ARM64 Code parallel im gleichen Prozess zu haben. Der für ARM64EC kompilierte Code (z.B. die Hauptanwendung) läuft nativ auf dem ARM Prozessor, der x64 Code (z.B. Plugin oder ne 3rd Party Library, die man nicht für ARM compilieren kann) wird emuliert.
Erklärung:
ARM64EC ist eine Abwandlung der ARM64 ABI. Das Application Binary Interface bestimmt z.B. die Größe und das Layout verschiedener Datentypen und wie Parameter an Funktionen übergeben werden. Letztendlich ist eine gemeinsamme ABI unter anderem entscheidend dafür, dass z.B. eine C-Funktion, die zum Zeitpunkt X kompiliert wurde und eine Funktion Y aufruft, die zu einem anderen Zeitpunkt kompiliert wurde die Parameter in einem Format übergibt, dass von Funktion Y auch korrekt interpretiert wird.
Für ARM64EC compilierter Code ist immer noch nativer ARM Code, nur wurde darauf geachtet, dass das Datenbinärformat kompatibel zu dem der Windows x64 ABI ist. Das ermöglicht es, dass eine regulär für x64 kompilierte Funktion eine ARM Funktion aufrufen kann (oder umgekehrt), ohne dass der Compiler mit dem der x64 Code erstellt wurde jemals was von der Windows ARM64 ABI (Egal ob mit oder ohne EC) gehört haben musste.
Im Detail ist das ganze natürlich noch wesentlich komplexer, aber ich hoffe das reicht zum Grundsätzlichen Verständnis.
TLDR:
Es geht schlicht darum binären x64 und binären ARM64 Code parallel im gleichen Prozess zu haben. Der für ARM64EC kompilierte Code (z.B. die Hauptanwendung) läuft nativ auf dem ARM Prozessor, der x64 Code (z.B. Plugin oder ne 3rd Party Library, die man nicht für ARM compilieren kann) wird emuliert.
Erklärung:
ARM64EC ist eine Abwandlung der ARM64 ABI. Das Application Binary Interface bestimmt z.B. die Größe und das Layout verschiedener Datentypen und wie Parameter an Funktionen übergeben werden. Letztendlich ist eine gemeinsamme ABI unter anderem entscheidend dafür, dass z.B. eine C-Funktion, die zum Zeitpunkt X kompiliert wurde und eine Funktion Y aufruft, die zu einem anderen Zeitpunkt kompiliert wurde die Parameter in einem Format übergibt, dass von Funktion Y auch korrekt interpretiert wird.
Für ARM64EC compilierter Code ist immer noch nativer ARM Code, nur wurde darauf geachtet, dass das Datenbinärformat kompatibel zu dem der Windows x64 ABI ist. Das ermöglicht es, dass eine regulär für x64 kompilierte Funktion eine ARM Funktion aufrufen kann (oder umgekehrt), ohne dass der Compiler mit dem der x64 Code erstellt wurde jemals was von der Windows ARM64 ABI (Egal ob mit oder ohne EC) gehört haben musste.
Im Detail ist das ganze natürlich noch wesentlich komplexer, aber ich hoffe das reicht zum Grundsätzlichen Verständnis.
