Arm64EC – Build and port apps for native performance on Arm

[jart]

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.

[yjftsjthsd-h]

And this kind of beautiful insanity is why you're one of my favorite developers of this era.

Also,

> I'm already putting the ARM code inside all my binaries.

Wait, I thought CPU architecture was the one limitation that did affect APE - you mean on unix-likes APE binaries are already compatible across amd64 and aarch64?

Edit: rereading https://justine.lol/cosmo3/ it does say that, doesn't it - and ARM64 listing "Windows (non-native)" just means that one platform uses (for the next few hours-days, at least...) emulation. That's amazing:)

[mappu]

I found the http://www.emulators.com/docs/abc_arm64ec_explained.htm article extremely helpful at understanding what the ABI is doing, you might like it too.

[justinfrankel]

If you have an Apple Silicon mac you can install Win11 in UTM and it works great for dev purposes. Can get the free builds via Windows Insider, too.

[lewurm]

> I actually think I'm going to rush out and buy a Windows ARM computer right now.

If you have an Apple Silicon machine you can run a Windows Insider build via UTM in a VM.

[zorgmonkey]

I'm pretty sure the API you'll want to detect that is IsWow64Process2.

[dwattttt]

PE headers have a field for machine type, you're looking for Machine in FileHeader: https://learn.microsoft.com/en-us/windows/win32/debug/pe-for... and https://learn.microsoft.com/en-us/windows/win32/debug/pe-for...

EDIT: Or maybe what you're looking for is hybrid PEs? https://ffri.github.io/ProjectChameleon/new_reloc_chpev2/

[darby_nine]

It looks like this might be provided by "Arm64X", which does seem to encode the dual-arch nature at the binary level: https://learn.microsoft.com/en-us/windows/arm/arm64x-pe

[dboreham]

> could detect that it's being emulated

Down the rabbit hole...

> buy a Windows ARM computer

You can still get Surface Pro X (16G/LTE) on Amazon for $800

[szundi]

Quickly create a donation page, you have this moment haha

[Aissen]

A long-term contributor to LuaJIT (@corsix) added Arm64EC support and introduced the franken ABI at FOSDEM 2024, with a very entertaining talk: https://fosdem.org/2024/schedule/event/fosdem-2024-1762-arm6...

[classichasclass]

This ( https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi ) feels a lot like a modern rethinking of Universal Procedure Pointers (i.e., between PowerPC and the 68K emulator on Power Macintosh).

[userbinator]

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.

[st_goliath]

> ... 16-bit realmode (V86), 16-bit protected mode, and 32-bit protected mode code in the same process by using different segment descriptors...

> ...Intel could've made ARM32/64-mode segments a reality...

While I myself admire this particular breed of masochism, the direction that Intel currently wants to take is apparently quite the opposite.

In May last year, they proposed X86S[1][2][3] which tosses out 16-bit support completely, along with 32 bit kernel mode (i.e. the CPU boots directly into 64 bit mode, 32 bit code is only supported in ring 3).

The proposal trims a lot of historical baggage, including fancy segmentation/TSS shenanigans, privilege rings 1 & 2, I/O port access from ring 3, non-flat memory models, etc... limiting the CPU to 64 bit kernel mode, and 64 or 32 bit x86 user mode. With the requirement for 64 bit kernel mode, it effectively also removes un-paged memory access.

[1] https://en.wikipedia.org/wiki/X86-64#X86S

[2] https://www.intel.com/content/www/us/en/developer/articles/t...

[3] https://news.ycombinator.com/item?id=36006446

[Dwedit]

For x64, there's OTVDM to run Windows 3.1 applications.

[sylware]

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.

Everything seems to converge more and more toward RISC-V these days.

[Symmetry]

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.

[frozenport]

Struggling with the use case.

It seems like this is when you have the source or the libs but choose to mix x86 and arm?

It would seem if you have the source etc you should just bite the bullet and port everything.

[adamjs]

Two use-cases jump to mind:

* Allows incremental porting of large codebases to ARM. (It's not always feasible to port everything at once-- I have a few projects with lots of hand-optimized SSE code, for example.)

* Allows usage of third-party x64 DLLs in ARM apps without recompilation. (Source isn't always available or might be too much of a headache to port on your own.)

[avidphantasm]

I feel like binary translation is a better approach. It’s a temporary workaround that allows users to use non-native programs while they are ported properly. ARM64EC seems like it will incentivize “eh that’s good enough” partial porting efforts that will never result in a full port, while making the whole system more complicated, with a larger attack surface (binary translation also makes the system more complicated, but it seems more isolated/less integrated with the rest of OS).

[anaisbetts]

The use-case is huge apps that have a native plugin ecosystem, think Photoshop and friends. Regular apps will typically just compile separate x64 and ARM64 versions

[doctorpangloss]

Yes, bite the bullet and port. Of course it makes no sense.

These sorts of things are only conceived in conversations between two huge corporations.

Like Microsoft needs game developers to build for ARM. There’s no market there. So their “people” author GPT-like content at each other, with a ratio of like 10 middlemen hours per 1 engineer hour, to agree to something that narratively fulfills a desire to build games for ARM. I can speculate endlessly how a conversation between MS and EA led to this exact standard but it’s meaningless, I mean both MS and EA do a ton of things that make no sense, and I can’t come up with nonsense answers.

Anyway, so this thing gets published many, many months after it got on some MS PM’s boss’s partner’s radar. Like the fucking devices are out! It’s too late for any of this to matter.

You can’t play Overwatch on a Snapdragon whatever (https://www.pcgamer.com/hardware/gaming-laptops/emulation-pr... ) End of story. Who cares what the ABI details are.

Microsoft OWNS Blizzard and couldn’t figure this out. Whom is this for?

[Tempest1981]

> requires the use of the Windows 11 SDK and is not available on Windows 10 on Arm.

So what should developers do re: Win10 users? Separate builds for them?

[goosedragons]

Is it really even a big enough concern to think about them? Windows 10 on ARM lacks x64 emulation support and the devices never sold well. I can't imagine there's too too many Windows 10 on ARM devices hanging around still running Windows 10.

[pjmlp]

From Microsoft's point of view, ignore them after 2025, unless they pay big.

In reality, yes, different builds, like it already happened with previous Windows versions.

[AshamedCaptain]

The same thing you do for users of all previous failed windows on arm attempts?

If you meant x86 win10 users you can use the win11 sdk to target them

[TiredOfLife]

Only the first Snapdragon 835 is not capable to run windows11. Starting with Snapdragon 850 all are compatible.

Snapdragon 835 is also horribly slow.

[spullara]

How is this different than what Apple did for the x86 -> ARM transition?

[duskwuff]

Rosetta 2 operates on the process level -- on an Apple Silicon system, a process can run an ARM executable and run all ARM code, or can run an x86_64 executable and run all x86_64 code. ARM64EC allows processes to run a mixture of native and emulated code. Whether this is actually useful is debatable, but the option exists.

[anaisbetts]

ARM64EC is usually for stuff like plugins or really large apps - most people will simply compile an ARM64 and x64 version of their app

[tedunangst]

It requires you to recompile your application a third time if you want to load x64 plugins, and then it becomes incompatible with arm plugins.

[nomercy400]

So is this Arm64EC Windows-only? Is it standardized?

If not, is this not just another target architecture? You cannot use it on arm64 architectures, and your app already supports x86.

[ComputerGuru]

It’s not anything special, it’s arm code compiled with the x64 abi. The theory behind it is simple enough.