Hacker News Reader

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)

[0]: https://gmplib.org/repo/gmp/rev/5f32dbc41afc

> 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).

Sorry but "we need a new universal ABI standard." asks for https://xkcd.com/927/

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 Can’t Actually Parse A C Header" -- this is, IMO, the most actionable objection that the article raises.

You don't need to parse C headers in order to use the same ABI. You can read DWARF info which is designed to convey type definitions, function/method prototypes etc. in a machine-readable way. It's already there, no need for a separate "IDL" standard at all.

> You could imagine a subset of C that does away with macros, typedefs, etc. in order to be easier to parse, and in doing so forms a more accessible ABI specification language. That seems eminently doable. But parsing is only part of the overall battle: actually implementing the ABI for 176 triples seems like the bigger problem. Especially when you add the ABI-impacting function attributes mentioned in the tweet.

A more reasonable option would be to have a better-defined format to describe the ABI (let's call it the Depandable Wanted Abi Recall Format) and have the C compiler output that DWARF for each header. Then other languages that want to make use of that ABI only need to parse the intermediate format and don't need to care about all the ugly details of the source language.

> You could imagine a subset of C that does away with macros, typedefs, etc. in order to be easier to parse, and in doing so forms a more accessible ABI specification language.

A start? https://github.com/cil-project/cil

> This article is hard to parse because it doesn't present any alternatives that the author considers better.

Much of the content posted on HN nowadays is like this.