Wow! This might actually make it possible for Actually Portable Executable to support running on Windows ARM. I'm already putting the ARM code inside all my binaries. There's just never been a way to encode that in the PE headers. But if my emulated WinMain() function for x86-64 could detect that it's being emulated and then simply ask a WIN32 API to jump to the ARM entrypoint instead, it'd be the perfect solution to my problems. I actually think I'm going to rush out and buy a Windows ARM computer right now.
A long-term contributor to LuaJIT (@corsix) added Arm64EC support and introduced the franken ABI at FOSDEM 2024, with a very entertaining talk: <a href="https://fosdem.org/2024/schedule/event/fosdem-2024-1762-arm64ec-microsoft-s-emulation-frankenstein/" rel="nofollow">https://fosdem.org/2024/schedule/event/fosdem-2024-1762-arm6...</a>
This ( <a href="https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi" rel="nofollow">https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi</a> ) feels a lot like a modern rethinking of Universal Procedure Pointers (i.e., between PowerPC and the 68K emulator on Power Macintosh).
Windows 9x can run 16-bit realmode (V86), 16-bit protected mode, and 32-bit protected mode code in the same process by using different segment descriptors. Too bad amd64 wasn't compatible with that model, nor the virtualisation features that came afterwards, or Intel could've made ARM32/64-mode segments a reality if they decided to add an ARM decoder to their microarchitecture.
Funny, I started to code some of my linux x86_64 programs... using RV64 assembly (the new C), with a small in-process RV64 assembly interpreter.<p>Everything seems to converge more and more toward RISC-V these days.
Sounds similar to what NVidia was doing with their Project Denver cores, using a mix of emulated ARM and native VLIW instructions with gradual compilation from one to another.
Struggling with the use case.<p>It seems like this is when you have the source or the libs but choose to mix x86 and arm?<p>It would seem if you have the source etc you should just bite the bullet and port everything.
> requires the use of the Windows 11 SDK and is not available on Windows 10 on Arm.<p>So what should developers do re: Win10 users? Separate builds for them?
So is this Arm64EC Windows-only? Is it standardized?<p>If not, is this not just another target architecture? You cannot use it on arm64 architectures, and your app already supports x86.