ABI vs C++ Standard

Question

J'essaie de comprendre la différence dans un ABI (disons pour le système V) et le standard C++. Ainsi, la norme C++ détermine simplement le C++ légal, de sorte qu'un compilateur peut le transformer en un code d'assemblage adéquat. L'ABI régule alors comment ce code d'assemblage interagit avec l'architecture x86? Est-ce la comparaison de niveau supérieur entre les deux?

La raison pour laquelle je demande est que, étant intéressé par un logiciel à faible latence, je me demande quelle serait la valeur de la lecture de l'ABI?

Answer 1

La norme définit ce qu'un programme doit faire en fonction du code que vous écrivez. L'ABI définit comment cela est implémenté pour une plate-forme particulière afin que le code compilé dans différentes exécutions (éventuellement par différents compilateurs/version) puisse interagir.

C'est, lorsque vous écrivez:

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

La norme définit le comportement: un appel à cette fonction provoque l'impression de la valeur de l'argument. L'ABI détermine comment l'assembly est généré pour que la fonction puisse être appelée (comment est le nom de f?) L'argument peut être passé (l'argument sera-t-il quelque part dans la pile? Dans un registre?). En ce qui concerne la partie en gras de la question ... eh bien, cela dépend. Les ABI sont des lectures lourdes, et il est difficile de les lire et de les comprendre. Mais vous devriez au moins être familier avec certaines des bases, comme calling conventions (quel est le coût de passage d'un objet de type T?) ... Au-delà, je ferais une approche réactive: profil et si vous avez besoin de comprendre ce que est en cours, l'ABI pourrait aider.

La plupart des programmeurs ne connaissent pas l'ABI pour leur plate-forme et ils vivent aussi heureux. J'ai surtout fait plusieurs allers-retours pour comprendre certaines particularités du comportement des programmes.

Answer 2

Pour votre question directe: Comprendre l'ABI vous aidera dans une certaine mesure. Mais l'ABI ne vous dira pas ce qui est efficace dans une application C++ particulière en tant que telle - par exemple, l'effet de l'utilisation de l'inline - qui peut être bénéfique et préjudiciable. De même, le choix d'utiliser vector par rapport au tableau de style C peut être bénéfique dans certains cas, mais dans d'autres cas, cela fait si peu de différence que cela ne vaut pas la peine de passer de l'un à l'autre.

Un logiciel à faible latence consiste beaucoup plus à comprendre ce que le compilateur fait EN GÉNÉRAL avec un code particulier qu'à savoir exactement ce que le paragraphe 13.6.2 de l'ABI dit sur la façon dont la VTABLE est organisée - à moins bien sûr que le code particulier que vous compilez est directement affecté par la mise en page VTABLE - la plupart du temps ce n'est pas un problème (au-delà de la compréhension qu'une fonction virtuelle est un appel indirect, qui peut être un peu plus lent que l'appel direct correspondant Vous pouvez vous soucier de choses comme "Combien de registres sont utilisés pour transmettre des arguments", mais sachant si le compilateur utilise R0, R1, R2 ou R13, R14 et bien plus que la version inline de la fonction. R15 comme les trois re gisters pour passer des arguments est beaucoup moins important. Et surtout, peu importe combien vous PENSEZ comprendre ce que fait le compilateur, en regardant la sortie de l'assembleur, en exécutant le code à travers un profileur, etc., vous en apprendrez BEAUCOUP plus que de lire la spécification ABI. Rappelez-vous que dans le code typique, 90% du temps est passé dans 10% du code. La fixation de la "lenteur" d'une fonction qui utilise 0,001% du temps d'exécution total est probablement un effort inutile.