💾 Archived View for namno.duckdns.org › blog › 2024-05-01.gmi captured on 2024-09-29 at 00:02:10. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

C cannot solve ABI

C ABI is a mess. Legacy types like log shift in lenght depending on compiler intmax isn't the longest integer available, applications are chained to decisions made decades ago, and other laguages have to parse this mess to talk to each other even if neither of them are C. Later point makes some people resent C, but C merely holds back the real horror that is programers just making up calling convention for each function in assembly. If C is to be defeated, whatever takes it's place will also have to take this burden. Given that the most "anti-C" language Rust breaks it's own internal ABI on purpose between versions I doubt that anyone wants that.

Why things suck

C types are wacky. There is int, long long, float, long double intmax_t, size_t, ptrdiff_t, int_least16_t and many more. Some of them exist because in 70s you could have cpu with 12 bit long byte, some of them exist because pointers and floating point numbers are weird and some of them are attemt to fix this mess while trying to respect werid archetecture that exist out there. In theory there is nothing wrong with this, just declare function with types that you need and compiler will figure out how to shuffle bits around depending on archetecture. The problem with this is that:

Sometimes archetecures have backwards-compatable updates that can operate on more types and semantincs of types break
Sometimes different compilers disagree about what type should actually be, especially when archetecture doesn't have instructions to deal with it nativly and so it is actually ends up being a hidden struct
Even if they agree on layout of the type, they may not agree whether some type can be placed into register when calling other function or retuning to callee.

C header files don't provide nearly enough information. The only solution is to either replace them or to suppliment them.

What should be done

I think that basic types that can be operated on by instructions should be provided by analog of standard library. These types should be used to describe more complex types. Both of those should be used in layout of fucntion call and return, including order of arguments on stack and which arguments occupy which registers.

This would necesitate specification of registers, which would make it much haredr to make portable programs. Thankfully, such descriptions can be generated automatically, which would allow new versions of ABI to change.