We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Arm64EC: Microsoft's emulation Frankenstein

Formale Metadaten

Titel
Arm64EC: Microsoft's emulation Frankenstein
Serientitel
Anzahl der Teile
798
Autor
Mitwirkende
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Arm64EC ("Emulation Compatible") is Microsoft's latest answer to emulating x86_64 on arm64, allowing code from both architectures to coexist in a single address space, so that an application can be incrementally ported from x86_64 to arm64. I'll cover what Arm64EC is, postulate on why it is the way it is, and lessons learnt from porting LuaJIT to it. What if there was a CPU (and associated C toolchain) capable of executing both x86_64 and arm64 instructions, cheaply switching back and forth at any function call boundary? While there isn't such a thing, Arm64EC emulates such a CPU - any x86_64 code is emulated, and any arm64 code needs to contort itself slightly to allow cheap switching in to and out of the emulator. The result is something of an emulation Frankenstein, but just maybe it'll help adoption of Windows on arm64. Speaking about a Windows feature at an open source event might seem initially odd, but things can be intellectually interesting regardless of origin, and open source tooling such as Wine and LLVM have started to add some support for it, and open source developers might want to port their applications to it (as I have done for LuaJIT).