Hacker News Reader

Hacker News

Comment by speed_spread | Hacker News Reader

Full thread

speed_spread

Would it possible to AOT-recompile from x86 to aarch64? Or will it all be emulated forever?

View on HN

Yes i dont see why not. At least on the surface technical level.

I used to work at ms on xbox backcompat games and we AOT recompile PowerPC arch to x86. (Xbox 360 to Xbox one).

You could likely aot recompile any arch with enough resources to fix up issues and things.

One key difference is older games were fixed so no more updates. It can be a little trickier with modern games still taking updates but could be done.

Not possible to fully AOT for all applications because you don't know which ones do JIT compilation to generate x86 code at runtime. Many games make use of LuaJIT, for example.

LuaJIT would also work with ARM though, so would it be possible to swap it out?

Indeed, LuaJIT support for Windows/Arm64 was added in https://github.com/LuaJIT/LuaJIT/issues/593, and there’s experimental out-of-tree support for Windows/Arm64EC in https://github.com/LuaJIT/LuaJIT/issues/1096

Swapping out is possible only if there are shared libraries though.

For statically linked programs is there anything that can be done?

Valve does a lot of hacks in Proton to make particular games run better. I think swapping a static library might also be possible if you target a particular game.

Very likely yes (Rosetta for the Mac already does this), but the big issue is that a ton of Unity games use JIT compiled Mono, and that would require dynamic recompilation, which as we've seen with Rosetta, would lead to terrible realtime performance

Rosetta does do AOT recompilation when it can.

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

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