4 ms·

Yes, it is possible to make worse ABIs than C's. That's not a surprise. Doesn't mean C's is automagically the best possible. Something that, at the very least,

by dzaima 5y ago

Yes, it is possible to make worse ABIs than C's. That's not a surprise. Doesn't mean C's is automagically the best possible. Something that, at the very least, doesn't have varying sizes for the same type between architectures/OSes, and precisely defines structure layout/padding, would be vastly better. (not saying that's a realistic thing to get at this point, but doesn't change the fact that it'd be much nicer.)

rayiner 5y ago
I’m not saying it’s the best thing, but I’m not sure you can get much better. A lot of things defined by the C ABI are things you’d have to do anyway if you’re compiling to native code (structure alignment, where’s the stack, what’s called-save, callee-save, where do you find the return value, etc.) Targeting the C ABI’s set of choices isn’t that different from targeting a different set of choices. And there are gratuitous differences in C ABIs, for sure. But often there’s good reasons. X86 had no register arguments because few registers; same reason it had no thread pointer. RISC architectures had weird limitations on unaligned access, etc. affecting struct layout. Maybe I’m being dense. What does a good alternative look like? CORBA?
- dzaima 5y ago
  Between architectures you'd indeed need quite a few differences, but for the same architecture it'd be nice if things more or less agreed on things. Specifically, I think it'd be very reasonable & possible to have an ABI that has various floats & integers (specified width of course), and pointers & structures, that has consistent conservative padding on all architectures and precisely one way any given structure is laid out in memory (ok, maybe two, with LSB & MSB integers; but I think that's literally all the variation there is (and MSB is nearly dead too)). Not the most efficient thing on all architectures, but for language inter-communication it shouldn't be too bad to lose a couple nanoseconds here and there, and I'd guess it'd outweigh the alternative of needing more generic (and thus, less optimized) code handling each individually.
- adgjlsfhk1 5y ago
  the big issues with C are that it doesn't specify the size of it's integer types.
  - valleyer 5y ago
    The various C ABIs definitely do, though. And you generally know which C ABI you need to interact with (the __int128_t example from the article just seems like a bug -- luckily use of that type is rare).
- jcranmer 5y ago
  If I could design my own cross-language ABI, I'd make these differences from C: * Use fixed-size types instead of the 5 types for 4 integer sizes (is long 32-bit or 64-bit?) * Allow multiple return values [so you could use multiple return registers, especially on non-register-starved arches] * Allow unwind ABI (C has no way to permit unwinding!) * Dedicated types for pointer + size for arrays * Dedicated string type (i.e., distinguish between &[u8] and &str in Rust terms) * Something that allows for vtables would be nice * Something that encodes ownership (and eventual deallocation) is also potentially valuable

by dzaima 5y ago

rayiner 5y ago

I’m not saying it’s the best thing, but I’m not sure you can get much better. A lot of things defined by the C ABI are things you’d have to do anyway if you’re compiling to native code (structure alignment, where’s the stack, what’s called-save, callee-save, where do you find the return value, etc.) Targeting the C ABI’s set of choices isn’t that different from targeting a different set of choices. And there are gratuitous differences in C ABIs, for sure. But often there’s good reasons. X86 had no register arguments because few registers; same reason it had no thread pointer. RISC architectures had weird limitations on unaligned access, etc. affecting struct layout. Maybe I’m being dense. What does a good alternative look like? CORBA?

dzaima 5y ago
Between architectures you'd indeed need quite a few differences, but for the same architecture it'd be nice if things more or less agreed on things. Specifically, I think it'd be very reasonable & possible to have an ABI that has various floats & integers (specified width of course), and pointers & structures, that has consistent conservative padding on all architectures and precisely one way any given structure is laid out in memory (ok, maybe two, with LSB & MSB integers; but I think that's literally all the variation there is (and MSB is nearly dead too)). Not the most efficient thing on all architectures, but for language inter-communication it shouldn't be too bad to lose a couple nanoseconds here and there, and I'd guess it'd outweigh the alternative of needing more generic (and thus, less optimized) code handling each individually.
adgjlsfhk1 5y ago
the big issues with C are that it doesn't specify the size of it's integer types.
- valleyer 5y ago
  The various C ABIs definitely do, though. And you generally know which C ABI you need to interact with (the __int128_t example from the article just seems like a bug -- luckily use of that type is rare).
jcranmer 5y ago
If I could design my own cross-language ABI, I'd make these differences from C: * Use fixed-size types instead of the 5 types for 4 integer sizes (is long 32-bit or 64-bit?) * Allow multiple return values [so you could use multiple return registers, especially on non-register-starved arches] * Allow unwind ABI (C has no way to permit unwinding!) * Dedicated types for pointer + size for arrays * Dedicated string type (i.e., distinguish between &[u8] and &str in Rust terms) * Something that allows for vtables would be nice * Something that encodes ownership (and eventual deallocation) is also potentially valuable