3 ms·

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 indep

by 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

by okanat 2mo ago

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