3 ms·

Should have a (2022) in the title, not that anything has changed (AFAIK), but the sky didn't fall either ;) In the end, OS/CPU combinations define ABIs, compil

Should have a (2022) in the title, not that anything has changed (AFAIK), but the sky didn't fall either ;) In the end, OS/CPU combinations define ABIs, compiler toolchains (no matter what language) can't do much more then follow (if they want to be able to talk to the operating system at least). E.g. if one day operating systems implement stable Rust-friendly ABIs, then C compilers will have to adapt to those conventions instead.

okanat 2mo ago
OS and CPU combination define their ABI as "whatever our most popular / default compiler did in 90s". That's the problem with C-based ABIs. OS ABIs aren't independent of the language. So any new language must include a C compiler within for ABI access. See https://faultlore.com/blah/c-isnt-a-language/ https://faultlore.com/blah/c-isnt-a-language/ for more detailed analysis.
- flohofwoe 2mo ago
  Sure, but the C standard is the wrong place to do anything about the "problem". Also IIRC it was really only UNIX which had this "whatever our C compiler does" mishmash. On most other operating systems it was the other way around, C compilers had to implement whatever calling convention the OS already had defined before there even was a C compiler for that OS (for instance early Windows version used a PASCAL calling conventions, and others (CP/M, DOS, AmigaOS...) some random rules that were most convenient for handwritten assembly code). PS: and yeah I know that other article (or rather: incoherent rant). It's basically a lot of barking up the wrong tree.
  - imtringued 2mo ago
    It's barking up the right tree. I don't want to say more, because that would tip off competitors and I'm just a lone wolf working on this.
- bigfishrunning 2mo ago
  > OS ABIs aren't independent of the language. I'd push back on this a bit. The ABI is "put the arguments on the stack this way and jump to this address". The fact that it's easy to do in C doesn't really make a difference, or make that process "C specific" at all, any other language would need to do the same thing. If you require those arguments to represent rust objects or be reference-counted in some way, it would impose more restrictions on the caller, not fewer.
  - flohofwoe 2mo ago
    Rust basically would need to specify the interior memory layout of basic types like Result or Option. But to be pedantic, not even C has a standardized memory layout for structs, only some accidential common conventions that work for some types but not others

okanat 2mo ago

OS and CPU combination define their ABI as "whatever our most popular / default compiler did in 90s". That's the problem with C-based ABIs. OS ABIs aren't independent of the language. So any new language must include a C compiler within for ABI access. See https://faultlore.com/blah/c-isnt-a-language/ https://faultlore.com/blah/c-isnt-a-language/ for more detailed analysis.

flohofwoe 2mo ago
Sure, but the C standard is the wrong place to do anything about the "problem". Also IIRC it was really only UNIX which had this "whatever our C compiler does" mishmash. On most other operating systems it was the other way around, C compilers had to implement whatever calling convention the OS already had defined before there even was a C compiler for that OS (for instance early Windows version used a PASCAL calling conventions, and others (CP/M, DOS, AmigaOS...) some random rules that were most convenient for handwritten assembly code). PS: and yeah I know that other article (or rather: incoherent rant). It's basically a lot of barking up the wrong tree.
- imtringued 2mo ago
  It's barking up the right tree. I don't want to say more, because that would tip off competitors and I'm just a lone wolf working on this.
bigfishrunning 2mo ago
> OS ABIs aren't independent of the language. I'd push back on this a bit. The ABI is "put the arguments on the stack this way and jump to this address". The fact that it's easy to do in C doesn't really make a difference, or make that process "C specific" at all, any other language would need to do the same thing. If you require those arguments to represent rust objects or be reference-counted in some way, it would impose more restrictions on the caller, not fewer.
- flohofwoe 2mo ago
  Rust basically would need to specify the interior memory layout of basic types like Result or Option. But to be pedantic, not even C has a standardized memory layout for structs, only some accidential common conventions that work for some types but not others