сборка — ABI против C ++ Standard
Я пытаюсь понять разницу в ABI (скажем, для System V) и C ++ Standard. Таким образом, стандарт C ++ просто определяет допустимый C ++, чтобы компилятор мог превратить его в адекватный ассемблерный код. Затем ABI регулирует, как этот ассемблерный код взаимодействует с архитектурой x86? Это сравнение более высокого уровня между двумя?
Я спрашиваю, что, заинтересовавшись программным обеспечением с низкой задержкой, мне интересно, сколько будет стоить чтение ABI?
Решение
Стандарт определяет, что программа должна делать, основываясь на коде, который вы пишете. ABI определяет, как это реализовано для конкретной платформы, чтобы код, скомпилированный в разных прогонах (возможно, разными компиляторами / версией), мог взаимодействовать.
То есть когда ты пишешь:
void f(int i) { std::cout << i; }
Стандарт определяет поведение: вызов этой функции приведет к распечатке значения аргумента. ABI определяет, как генерируется сборка, чтобы можно было вызывать функцию (как называется f искаженный?) аргумент может быть передан (будет ли аргумент где-нибудь в стеке? в регистре?).
Что касается смелой части вопроса … ну, это зависит. ABI — тяжелые чтения, и их трудно читать и понимать. Но вы должны хотя бы знать некоторые основы, такие как соглашения о вызовах (какова стоимость передачи объекта типа T?) … Кроме того, я бы сделал этот реактивный подход: профиль, и если вам нужно понять, что происходит, ABI может помочь.
Большинство программистов не знают ABI для своей платформы и живут так же счастливо. Я особенно пару раз ходил взад и вперед, чтобы понять некоторые особенности поведения программ.
Другие решения
Для вашего прямого вопроса: понимание ABI поможет вам в некоторой степени. Но ABI не скажет вам, что эффективно в конкретном приложении C ++ как таковом — например, эффект от использования встраивания — что может быть полезным и вредным. Точно так же, выбор использовать vector Матрица стилей C или C может дать преимущества в некоторых случаях, но в других местах это так мало меняет, что не стоит переходить с одного на другое.
Программное обеспечение с малой задержкой гораздо больше понимает, что делает компилятор В ОБЩЕМ с каким-то конкретным фрагментом кода, чем точно знает, что в параграфе 13.6.2 в ABI говорится о том, как организован VTABLE — если, конечно, конкретный код не является вашим. Компиляция VTABLE напрямую влияет на компиляцию — в большинстве случаев это не проблема (помимо понимания того, что виртуальная функция является косвенным вызовом, который может быть немного медленнее, чем соответствующий прямой вызов, а для простых функций будет значительно медленнее). чем встроенная версия функции.
Вы, конечно, заботитесь о таких вещах, как «Сколько регистров используется для передачи аргументов», но гораздо менее важно знать, использует ли компилятор R0, R1, R2 или R13, R14 и R15 в качестве трех регистров для передачи аргументов.
И самое главное, независимо от того, насколько вы ДУМАЕТЕ, что вы понимаете, что делает компилятор, просматривая выходные данные ассемблера, пропуская код через профилировщик и т. Д., Вы получите НАМНОГО больше об этом, чем чтение спецификации ABI. Помните, что в типичном коде 90% времени тратится на 10% кода. Исправление «медлительности» функции, которая использует 0,001% от общего времени выполнения, вероятно, является напрасной тратой усилий.
detector