4 ms·

This article is hard to parse because it doesn't present any alternatives that the author considers better. - You have to speak the C ABI to talk to the OS --

This article is hard to parse because it doesn't present any alternatives that the author considers better. - You have to speak the C ABI to talk to the OS -- yes, if you want an OS to support more than one language, or you want multiple languages within a single process, you need a common ABI of some sort. What is the alternative that doesn't involve a common ABI? - C has too many ABIs -- yes, there are a lot of different kinds of hardware, and sometimes multiple software ecosystems evolved in parallel on the same hardware (eg. Windows and Linux). What is the alternative? - ABI changes are hard to make in a non-breaking way -- yes they are. It's fundamentally a hard problem. You could compile everything from source every time, but the open-source world seems to have decided that there isn't enough time or CPU power to "live at head" and build from source every time, like Google does: https://abseil.io/about/philosophy#we-recommend-that-you-choose-to-live-at-head https://abseil.io/about/philosophy#we-recommend-that-you-cho... (Disclosure: I work at Google). - "You Can’t Actually Parse A C Header" -- this is, IMO, the most actionable objection that the article raises. 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. As a C fan, it's hard to see the language itself blamed for what are (in my view) just fundamentally difficult problems.

dzaima 5y ago
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.
- haberman 5y ago
  > 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/software-standards/abi 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-arm64-code-for-apple-platforms 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.
  - dzaima 5y ago
    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.
zozbot234 5y ago
> "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.
acuozzo 5y ago
> 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 https://github.com/cil-project/cil
account42 5y ago
> 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.
gaws 5y ago
> 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.

dzaima 5y ago

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.

haberman 5y ago
> 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/software-standards/abi 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-arm64-code-for-apple-platforms 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.
- dzaima 5y ago
  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.

zozbot234 5y ago

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

acuozzo 5y ago

> 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 https://github.com/cil-project/cil

account42 5y ago

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

gaws 5y ago

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