ABI vs C++ Standard

Question

I am trying to understand the difference in an ABI (say for System V) and the C++ Standard. So the C++ standard just determines legal C++ so that a compiler can turn this in to adequate assembly code. The ABI then regulates how this assembly code interacts with the x86 architecture? Is that the higher level comparison between the two?

My reason for asking is that being interested in low latency software I wonder how much value reading the ABI would contain?

Answer 1

The standard defines what a program should do based on the code that you write. The ABI defines how that is implemented for a particular platform so that code compiled in different runs (possibly by different compilers/version) can interact.

That is, when you write:

void f(int i) { std::cout << i; }

The standard defines the behavior: a call to that function will cause the printout of the value of the argument. The ABI determines how the assembly is generated so that the function can be called (how is the name of f mangled?) the argument can be passed in (will the argument be somewhere in the stack? in a register?).

Regarding the bold part of the question... well, it depends. ABIs are heavy reads, and it is hard to read and understand them. But you should at least be familiar with some of the basics, like calling conventions (what is the cost of passing an object of type T?)... Beyond that I would make that a reactive approach: profile and if you need to understand what is going on, the ABI might help.

Most programmers don't know the ABI for their platform and they live as happily. I particularly have gone back and forth a couple of times to understand some peculiarities of the behavior of programs.

Answer 2

For your direct question: Understanding the ABI will help you to some degree. But the ABI will not tell you what is efficient in a particular C++ applicaton as such - for example, the effect of using inlining - which can be beneficial and detrimental. Similarly, the choice to use vector vs. C style array may give benefits in some cases, but other places, it makes so little difference that it's not worth changing from one to the other.

Low-latency software is much more about understanding what the compiler does IN GENERAL with some particular piece of code, than knowing exactly what paragraph 13.6.2 in the ABI says about how the VTABLE is organised - unless of course, the particular code you are compiling is affected directly by the VTABLE layout - most of the time it is not an issue (beyond understanding that a virtual function is an indirect call, which can be a little slower than the corresponding direct call, and for simple functions would be significantly slower than an inlined version of the function.

You certainly do care about things like "How many registers are used to pass arguments", but knowing whether the compiler uses R0, R1, R2 or R13, R14 and R15 as the three registers to pass arguments is much less important.

And most importantly, no matter how much you THINK you understand what the compiler does, looking at the assembler output, running the code through a profiler, etc, will tell you MUCH more about it than reading the ABI specification. Remember that in typical code, 90% of the time is spent in 10% of the code. Fixing the "slowness" of a function that uses 0.001% of the total runtime is probably wasted effort.