4 ms·
Now that these differences are documented, are they going to have to be maintained forever? Or is there any chance that the Apple ABI could converge to the AArc
by nneonneo 5y ago
Now that these differences are documented, are they going to have to be maintained forever? Or is there any chance that the Apple ABI could converge to the AArch64 ABI over time?
- gjsman-1000 5y agoProbably forever. AFAIK IANAE (I am not an engineer), to change this would require breaking compatibility with all iOS and macOS ARM binaries and telling developers that for optimal performance without using Rosetta 3, they need to compile toward "(new) Apple Silicon." It's probably not going to happen.
- deleted 5y ago[deleted]
- somebody_amzn 5y agoYou don't need a translator. The ABI is a software construct, not an hardware one. What would be needed though is to have two copies of the system libraries in such a case, targeting different ABIs. That's of course very unlikely to happen.
- saagarjha 5y agoThere are already two different ABIs for Apple silicon, although one (arm64e) is mostly reserved for Apple’s use at the moment. Apple could choose to finalize the ABI for that with x18 being available to applications, although this is quite unlikely.
- olliej 5y agoNo there aren’t and you know that. Arm64e has the exact same abi as arm64, but in arm64 mode the pac instructions are no ops. Otherwise as the parent says apple would need multiple copies of the system libraries.
- saagarjha 5y agoYeah, I understand that they are currently the same, I'm just saying that as Apple hasn't locked down the ABI yet so they could in the future choose to ship a new copy of all the libraries (as they do with x86_64h) for arm64e (well, split out arm64 slices) and for that ABI allow the use of x18. It would be pretty dumb, but it's possible.