4 ms·

The Apple ABI was burnt into physical hardware while ARM was still finalizing some of the 64-bit details, which is why there are minor differences. X18 is very

The Apple ABI was burnt into physical hardware while ARM was still finalizing some of the 64-bit details, which is why there are minor differences. X18 is very specifically called out as “for the platform: do not use”, though, so things like GNU MP [1] moaning that Apple hasn’t specified how they use x18, and them using it anyway are just ridiculous. ‘While we added support for Apple's new Arm based computers, our support has a problem. The problem is that Apple reserves CPU register x18, but GMP's mpn/arm64 assembly code uses that register. While GMP runs fine in our tests, we expect things to go awry in some execution situation. (Apple has not been kind enough to specify how they use x18. Therefore, we don't know what the consequences of using x18 might be.)’ [1] https://gmplib.org/ https://gmplib.org/

chrisseaton 5y ago
Are they not able to stop using the register? Why keep touching a rail that you've been told might be electrified?
- vetinari 5y ago
  Their code is older than M1. That rail, when supplied by other vendors, was not live.
  - chrisseaton 5y ago
    Yeah I get that... but that doesn't meet the current ABI so change it.
    - zorgmonkey 5y ago
      It is already fixed https://gmplib.org/repo/gmp/rev/5f32dbc41afc https://gmplib.org/repo/gmp/rev/5f32dbc41afc
  - stephencanon 5y ago
    But younger than Apple’s arm64 ABI, and younger than ARM’s ABI docs which reserve it for platform use. Any software intended to target multiple platforms should never have been using it.
smoldesu 5y ago
Unless Apple can produce a sufficient explanation of why you wouldn't use that register, I see no reason why developers wouldn't.
- aarch64 5y ago
  Here is ARM's explanation in the AAPCS64 (ARM 64-bit Architecture Procedure Call Standard): > Software developers creating platform-independent code are advised to avoid using r18 if at all possible. Most compilers provide a mechanism to prevent specific registers from being used for general allocation; portable hand-coded assembler should avoid it entirely. It should not be assumed that treating the register as callee-saved will be sufficient to satisfy the requirements of the platform. Virtualization code must, of course, treat the register as they would any other resource provided to the virtual machine. From: https://github.com/ARM-software/abi-aa/blob/2bcab1e3b22d55170c563c3c7940134089176746/aapcs64/aapcs64.rst https://github.com/ARM-software/abi-aa/blob/2bcab1e3b22d5517...
  - somebody_amzn 5y ago
    To elaborate: On Darwin, x18 is used as a scratch register in context switches on hardware where Meltdown mitigations are needed. As such, it is cleaned on each ctx switch on that hardware. On M1, it's currently usable by applications, but that is not part of the ABI contract and might change at any time without notice. On Windows, x18 is the TEB (thread environment block) register. It must as such _not_ be touched by apps either.
    - NobodyNada 5y ago
      > On Darwin, x18 is used [...] on hardware where Meltdown mitigations are needed. [...] On M1, it's currently usable by applications I’m confused. x18 is an ARM register, but I thought Meltdown only affected x86 chips. Were iOS devices vulnerable to Meltdown too? Or did you mean not x18 specifically but some equivalent OS-reserved x86 register?
      - 5y ago
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 ago
  Probably 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 ago
    You 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 ago
      There 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 ago
        No 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.
        5y ago
benou 5y ago
I think it was fixed 2 weeks after the announcement: https://gmplib.org/repo/gmp/rev/5f32dbc41afc https://gmplib.org/repo/gmp/rev/5f32dbc41afc I am more reading this as 'we just enabled compilation for Apple M1 but it is highly experimental, use at your own risk until it is properly fixed'. I think you misinterpreted their stance.

chrisseaton 5y ago

Are they not able to stop using the register? Why keep touching a rail that you've been told might be electrified?

vetinari 5y ago
Their code is older than M1. That rail, when supplied by other vendors, was not live.
- chrisseaton 5y ago
  Yeah I get that... but that doesn't meet the current ABI so change it.
  - zorgmonkey 5y ago
    It is already fixed https://gmplib.org/repo/gmp/rev/5f32dbc41afc https://gmplib.org/repo/gmp/rev/5f32dbc41afc
- stephencanon 5y ago
  But younger than Apple’s arm64 ABI, and younger than ARM’s ABI docs which reserve it for platform use. Any software intended to target multiple platforms should never have been using it.

smoldesu 5y ago

Unless Apple can produce a sufficient explanation of why you wouldn't use that register, I see no reason why developers wouldn't.

aarch64 5y ago
Here is ARM's explanation in the AAPCS64 (ARM 64-bit Architecture Procedure Call Standard): > Software developers creating platform-independent code are advised to avoid using r18 if at all possible. Most compilers provide a mechanism to prevent specific registers from being used for general allocation; portable hand-coded assembler should avoid it entirely. It should not be assumed that treating the register as callee-saved will be sufficient to satisfy the requirements of the platform. Virtualization code must, of course, treat the register as they would any other resource provided to the virtual machine. From: https://github.com/ARM-software/abi-aa/blob/2bcab1e3b22d55170c563c3c7940134089176746/aapcs64/aapcs64.rst https://github.com/ARM-software/abi-aa/blob/2bcab1e3b22d5517...
- somebody_amzn 5y ago
  To elaborate: On Darwin, x18 is used as a scratch register in context switches on hardware where Meltdown mitigations are needed. As such, it is cleaned on each ctx switch on that hardware. On M1, it's currently usable by applications, but that is not part of the ABI contract and might change at any time without notice. On Windows, x18 is the TEB (thread environment block) register. It must as such _not_ be touched by apps either.
  - NobodyNada 5y ago
    > On Darwin, x18 is used [...] on hardware where Meltdown mitigations are needed. [...] On M1, it's currently usable by applications I’m confused. x18 is an ARM register, but I thought Meltdown only affected x86 chips. Were iOS devices vulnerable to Meltdown too? Or did you mean not x18 specifically but some equivalent OS-reserved x86 register?
    - 5y ago

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 ago
Probably 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 ago
  You 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 ago
    There 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 ago
      No 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.
      - 5y ago

benou 5y ago

I think it was fixed 2 weeks after the announcement: https://gmplib.org/repo/gmp/rev/5f32dbc41afc https://gmplib.org/repo/gmp/rev/5f32dbc41afc I am more reading this as 'we just enabled compilation for Apple M1 but it is highly experimental, use at your own risk until it is properly fixed'. I think you misinterpreted their stance.