Hacker News new | ask | show | jobs
by sedatk 640 days ago
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 :)
1 comments
agosz 640 days ago
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.

link
sedatk 640 days ago
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.
link
agosz 639 days ago
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.
link