I don't think the author blames it on C. C didn't choose to become the ABI of 99% of the world. But yet, it is.
> You have to speak the C ABI to talk to the OS [...] What is your alternative that doesn't involve a common ABI?
Emphasis is on the _C_ ABI. The alternative is something that at least tries to be designed as a universal ABI.
> there are a lot of different kinds of hardware, and sometimes multiple software ecosystems evolved in parallel on the same hardware
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.
If such standardization could cut the number of ABIs in half, it'd still be a huge win. And I think it'd be possible to go much further than that. Furthermore, it may be possible to split orthogonal things apart, such that instead of e.g. 50 targets, you have 5 OS targets and 10 arch targets, each specifying a separate part of the ABI. (current ABIs obviously do this to some extent, but not in any specified & structured way)
> As a C fan, it's hard to see the language itself blamed for what are (in my view) just fundamentally difficult problems.
I also like C. I agree these are hard problems. But I don't think they're problems that C should be dealing with. But we're pretty much just stuck with C.
> 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)
> Emphasis is on the _C_ ABI. The alternative is something that at least tries to be designed as a universal ABI.
That's not an either-or. E.g. WinRT is an ABI that is specifically designed as cross-language, but it can be reduced to the C ABI (e.g. vtables are basically structs of function pointers etc).
I mean, yes, right now, it has ±0 chance to become a thing. Still doesn't make status quo any better, and does not at all change that such a universal ABI probably could be much better.
It's definitely a risk, but also the wide variety of ABIs are not currently competing, except in a few niches. There are no existing comprehensive standards I could support, as far as I'm aware.
> You have to speak the C ABI to talk to the OS [...] What is your alternative that doesn't involve a common ABI?
Emphasis is on the _C_ ABI. The alternative is something that at least tries to be designed as a universal ABI.
> there are a lot of different kinds of hardware, and sometimes multiple software ecosystems evolved in parallel on the same hardware
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.
If such standardization could cut the number of ABIs in half, it'd still be a huge win. And I think it'd be possible to go much further than that. Furthermore, it may be possible to split orthogonal things apart, such that instead of e.g. 50 targets, you have 5 OS targets and 10 arch targets, each specifying a separate part of the ABI. (current ABIs obviously do this to some extent, but not in any specified & structured way)
> As a C fan, it's hard to see the language itself blamed for what are (in my view) just fundamentally difficult problems.
I also like C. I agree these are hard problems. But I don't think they're problems that C should be dealing with. But we're pretty much just stuck with C.