Каково назначение регистра указателя кадра EBP?

Я новичок в ассемблере и заметил, что код x86, выдаваемый компиляторами, обычно сохраняет указатель кадра даже в режиме выпуска / оптимизации, когда он может использовать EBPрегистр для чего-то еще.

Я понимаю, почему указатель кадра может упростить отладку кода и может быть необходим, если он alloca()вызывается внутри функции. Однако в x86 очень мало регистров, и использование двух из них для хранения местоположения кадра стека, когда одного было бы достаточно, для меня не имеет смысла. Почему опускание указателя кадра считается плохой идеей даже в оптимизированных / выпускаемых сборках?

Указатель кадра - это ссылочный указатель, позволяющий отладчику узнать, где находится локальная переменная или аргумент с одним постоянным смещением. Хотя значение ESP изменяется в процессе выполнения, EBP остается неизменным, что позволяет достичь той же переменной при том же смещении (например, первый параметр всегда будет на EBP + 8, а смещения ESP могут значительно измениться, поскольку вы будете нажимать / выскакивать)

Почему компиляторы не выбрасывают указатель кадра? Поскольку с указателем кадра отладчик может выяснить, где локальные переменные и аргументы используют таблицу символов, поскольку они гарантированно имеют постоянное смещение относительно EBP. В противном случае не существует простого способа определить, где находится локальная переменная в любой точке кода.

Как упоминал Грег, это также помогает раскручивать стек для отладчика, поскольку EBP предоставляет список фреймов стека с обратной связью, что позволяет отладчику определять размер фрейма стека (локальные переменные + аргументы) функции.

Большинство компиляторов предоставляют возможность опускать указатели кадров, хотя это действительно затрудняет отладку. Этот параметр никогда не следует использовать глобально, даже в коде выпуска. Вы не знаете, когда вам нужно отладить сбой пользователя.

Просто добавляю свои два цента к уже хорошим ответам.

Наличие цепочки фреймов стека является частью хорошей языковой архитектуры. BP указывает на текущий кадр, где хранятся локальные переменные подпрограммы. (Локальные переменные имеют отрицательные смещения, а аргументы - положительные смещения.)

Идея о том, что это препятствует использованию в оптимизации идеально хорошего регистра, поднимает вопрос: когда и где оптимизация действительно стоит?

Оптимизация имеет смысл только в тесных циклах, которые 1) не вызывают функции, 2) где счетчик программ тратит значительную часть своего времени, и 3) в коде, который компилятор действительно когда-либо увидит (т.е. небиблиотечные функции). Обычно это очень небольшая часть всего кода, особенно в больших системах.

Другой код можно скрутить и сжать, чтобы избавиться от циклов, и это просто не имеет значения, потому что счетчика программ практически нет.

Я знаю, что вы об этом не спрашивали, но по моему опыту, 99% проблем с производительностью не имеют ничего общего с оптимизацией компилятора. У них есть все, что связано с чрезмерным дизайном.

Конечно, это зависит от компилятора. Я видел оптимизированный код, создаваемый компиляторами x86, которые свободно используют регистр EBP в качестве регистра общего назначения. (Я не помню, с каким компилятором я это заметил.)

Компиляторы также могут поддерживать регистр EBP для помощи при раскручивании стека во время обработки исключений, но опять же это зависит от точной реализации компилятора.

Однако у x86 очень мало регистров

Это верно только в том смысле, что коды операций могут адресовать только 8 регистров. Сам процессор на самом деле будет иметь гораздо больше регистров, чем это, и использовать переименование регистров, конвейерную обработку, спекулятивное выполнение и другие модные слова процессора, чтобы обойти этот предел. В Википедии есть хороший вводный абзац о том, что процессор x86 может сделать, чтобы преодолеть ограничение регистра: http://en.wikipedia.org/wiki/X86#Current_implementations .

Использование стековых фреймов стало невероятно дешевым в любом оборудовании, даже отдаленно современном. Если у вас дешевые фреймы стека, то сохранение пары регистров не так важно. Я уверен, что быстрые кадры стека по сравнению с большим количеством регистров были инженерным компромиссом, и быстрые кадры стека победили.

Сколько вы экономите на чистом регистре? Стоит ли оно того?