> If there was an explicit ABI standard though, evolving ecosystems would have to go through the standardization and thus you just couldn't get conflicting ABIs for the same thing.
But there are lots of reasons why projects/companies might want to create their own ABIs, or change existing ones. You seem to be suggesting that if an ABI standards body existed, that all vendors would be following a minimal and unified set of ABI standards. But the very examples given in the article contradict this vision. Arm64 does have an ABI standard (https://developer.arm.com/architectures/system-architectures...), but Apple chooses to deviate from it anyway with the aarch64-apple-* set of targets: https://developer.apple.com/documentation/xcode/writing-arm6...
I don't think this has anything to do with C per se. Whether it was the "C ABI" or the "Standard ABI (totally separate from C)", vendors would have incentives to do their own thing. Especially since this stuff all sits so close to the hardware, and the ABI has a significant impact on performance.
I'm not saying all would follow it, but at least they'd have to try to, or risk being poorly supported (unless they're already at the top of the food chain, but then they'd already just be the ones dictating new ABI standards anyway). The goal isn't to eliminate all variance, but to constrain the amount to which that is done, and have separated parts such that orthogonal problems can be dealt with separately.
I'd be surprised if a ton of applications in the wild aren't violating Apple's register x18 requirement, especially given that, as far as I can tell from searching, applications can just freely use it on macOS+Apple Silicon.
In my mind, an ABI standard would have some 3 parts - object layout on the heap, foreign function calling convention, and background requirements/standards (though i'm possibly missing some important part). The Apple changes would only affect the latter (assuming function calling has at least one volatile non-argument register, which could be reused for that). And object heap layout has pretty much no business being ever changed. (importantly, the first two would be only for cross-language communication; your language itself could do structures & calls however it likes)
edit: it seems that the ARM ABI itself names r18 "The Platform Register", allowing ABIs to change its meaning, and recommends programs to not use it if at all possible, so Apple's restriction isn't even that unreasonable.
> I'd be surprised if a ton of applications in the wild aren't violating Apple's register x18 requirement
macOS outright zeroed x18 on each context switch for a bit, and it's zeroed on each context switch as part of the Meltdown mitigation for older SoCs in iOS.
On Windows, x18 is used as the thread environment block pointer.
On Android, x18 is not accessible to third party apps as part of the ABI. It is reserved for the shadow call stack.
(tldr: on most OSes x18 is explicitly reserved by the platform)
see my edit - the ARMv8 ABI even specifies x18 to be possibly platform-defined. So those aren't unreasonable, and I'm probably overestimating how many things misuse it. But apparently that list includes GNU MP[0], and it's easy to view this problem as stemming from there not being a concrete ABI. (though, restricting the use of x18 on platforms that don't need it reserved could be pretty wasteful)
But there are lots of reasons why projects/companies might want to create their own ABIs, or change existing ones. You seem to be suggesting that if an ABI standards body existed, that all vendors would be following a minimal and unified set of ABI standards. But the very examples given in the article contradict this vision. Arm64 does have an ABI standard (https://developer.arm.com/architectures/system-architectures...), but Apple chooses to deviate from it anyway with the aarch64-apple-* set of targets: https://developer.apple.com/documentation/xcode/writing-arm6...
I don't think this has anything to do with C per se. Whether it was the "C ABI" or the "Standard ABI (totally separate from C)", vendors would have incentives to do their own thing. Especially since this stuff all sits so close to the hardware, and the ABI has a significant impact on performance.