4 ms·

A C++ ABI does not require an OS written in C++. It just requires all compiler implementations to agree to standardize on a single ABI and enshrine it in a spec

A C++ ABI does not require an OS written in C++. It just requires all compiler implementations to agree to standardize on a single ABI and enshrine it in a spec that any future implementations must abide by.

pjmlp 8y ago
A C++ compiler that needs to support multiple distinct ABIs? One per each platform, plus an additional one, agreed by all these guys? And the list is not 100% compliant, e.g. TI is missing. https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compilers https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compil... Not even C has managed to do it, what people conventionally refer as C ABI is actually the OS ABI. I still remember having to deal with multiple C ABI on MS-DOS and Windows static libraries.
gpderetta 8y ago
I'm really interested to know how a standard ABI would cover both little endian 32 bit x86 and big endian 64 bit POWER.
- eridius 8y ago
  Compilers already have ABIs, they're just compiler-specific and not documented. If they didn't have an ABI, then you couldn't link 2 C++ libraries together. In terms of having one spec that handles arbitrary architectures, maybe it could be defined relative to the C ABI? I don't actually know how what the internal ABIs used by the current crop of C++ compilers looks like, so I don't know if they could be expressed relative to the C ABI or not. Alternatively, one could come up with a set of configurable values that define what makes one architecture different from another (such as word size, long/pointer size (if different than word size), endianness, etc). You know, the stuff that the compiler already has to know about in order to compile for an architecture (and I'm pretty sure clang at the least already has a way to even define new target triples in terms of a set of configurable values for this sort of thing). I assume existing compilers don't invent entirely brand new ABIs for each new architecture but instead just adapt an internal standard C++ ABI to the new architecture using a similar process already. The same could be done for a public standard C++ ABI.

pjmlp 8y ago

A C++ compiler that needs to support multiple distinct ABIs? One per each platform, plus an additional one, agreed by all these guys? And the list is not 100% compliant, e.g. TI is missing. https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compilers https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compil... Not even C has managed to do it, what people conventionally refer as C ABI is actually the OS ABI. I still remember having to deal with multiple C ABI on MS-DOS and Windows static libraries.

gpderetta 8y ago

I'm really interested to know how a standard ABI would cover both little endian 32 bit x86 and big endian 64 bit POWER.

eridius 8y ago
Compilers already have ABIs, they're just compiler-specific and not documented. If they didn't have an ABI, then you couldn't link 2 C++ libraries together. In terms of having one spec that handles arbitrary architectures, maybe it could be defined relative to the C ABI? I don't actually know how what the internal ABIs used by the current crop of C++ compilers looks like, so I don't know if they could be expressed relative to the C ABI or not. Alternatively, one could come up with a set of configurable values that define what makes one architecture different from another (such as word size, long/pointer size (if different than word size), endianness, etc). You know, the stuff that the compiler already has to know about in order to compile for an architecture (and I'm pretty sure clang at the least already has a way to even define new target triples in terms of a set of configurable values for this sort of thing). I assume existing compilers don't invent entirely brand new ABIs for each new architecture but instead just adapt an internal standard C++ ABI to the new architecture using a similar process already. The same could be done for a public standard C++ ABI.