Hacker News Reader

Comment by sedatk | Hacker News Reader

Windows already AOT compiles x86 binaries to ARM64 when they are built with /ARM64EC option. It doesn't support AOT for older executables yet.

View on HN

ARM64EC requires source and it produces an ARM64EC executable, which runs close to ARM64 speeds. x86/x64 executables are emulated.

Just to clarify: yes, it requires the source AND re-building it. But, with a simple switch, you make your x86 code JITtable on ARM64. That's why it runs at native ARM64 speeds. Sometimes, you can't build natively for ARM64 due to some dependency, and this allows portions of your code to be faster at least.

Otherwise, if you have the source AND budget to rebuild, just build it natively for ARM64 of course :)

ARM64EC doesn't really make your code JITable. It is ARM64 code with thunks to enable transitions to x64 code. That's why it runs at near native speeds; not because of the JIT. The x64 portions of the binary do get JITed though, but the ARM64EC portions are usually much faster.

All x64 code gets JITed but that's regardless of whether ARM64EC is used or not; ARM64EC allows ARM64 applications to interface with x64 binaries.

Okay, I had assumed JIT for x64 wasn't possible (yet) and ARM64EC enabled that partially. So, ARM64EC images are actually native ARM code that can interact with emulated (+JITted) components. For some reason, I thought native ARM64 binaries already had this capability, but they don't. Thanks, that's actually a better state of affairs in Windows on ARM land.

Yes, that's correct! Unfortunately ARM64 can't fully interface with x64 code (e.g. you can't translate an ARM64 CONTEXT to an x64 one directly due to differing numbers of registers), so the backwards compatibility is restricted to ARM64EC only.

Reply on news.ycombinator.com