it’s transpiling the x86 code to ARM on the fly. I honestly would have thought it wasn’t possible
Apple’s been doing it for years. They try to do ahead of time transpiling wherever they can but they also do it on-the-fly for things like JITed code.
it’s transpiling the x86 code to ARM on the fly. I honestly would have thought it wasn’t possible
Apple’s been doing it for years. They try to do ahead of time transpiling wherever they can but they also do it on-the-fly for things like JITed code.
steventhedev@lemmy.world 5 days ago
I thought FAT binaries don’t work like that - they included multiple instruction sets with a header pointing to the sections (68k, PPC, and x86)
Rosetta to the best of my understanding did something similar - but relied on some custom microcode support that isn’t rooted in ARM instructions. Do you have a link that explains a bit more in depth on how they did that?
BorgDrone@lemmy.one 5 days ago
Fat binaries contain both ARM and x86 code, but I was referring to Rosetta, which is used for x86-only binaries.
Rosetta does translation of x86 to ARM, both AOT and JIT. It does translate to normal ARM code, the only dependency on a Apple-specific custom ARM extension is that the M-series processors have a special mode that implements x86-like strong memory ordering. This means Rosetta does not have to figure out where to place memory barriers, this allows for much better performance.
steventhedev@lemmy.world 5 days ago
That makes a lot of sense - I wonder if they also do the SIGSEGV trick like HotSpot to know when they need to JIT the next chunk of instructions