Яка мета реєстру покажчика кадру EBP?

Я початківець у мові складання і помітив, що код x86, що випромінюється компіляторами, зазвичай утримує покажчик кадру навколо навіть у режимі випуску / оптимізації, коли він може використовувати EBPреєстр для чогось іншого.

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

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

Чому компілятори не відкидають покажчик кадру? Оскільки за допомогою покажчика кадру, налагоджувач може з'ясувати, де локальні змінні та аргументи використовують таблицю символів, оскільки вони гарантовано постійно зміщуються до EBP. В іншому випадку існує непростий спосіб зрозуміти, де локальна змінна знаходиться в будь-якій точці коду.

Як згадував Грег, він також допомагає розмотати стек для налагоджувача, оскільки EBP надає зворотний зв'язаний список фреймів стека, тому дозволяє налагоджувачу визначити розмір кадру стека (локальні змінні + аргументи) функції.

Більшість компіляторів надають можливість опускати покажчики кадрів, хоча це робить налагодження дійсно важким. Ця опція ніколи не повинна використовуватися в усьому світі, навіть у коді релізу. Ви не знаєте, коли вам потрібно буде налагодити аварію користувача.

Просто додав два мої центи до вже хороших відповідей.

Це частина гарної мовної архітектури - мати ланцюжок стекових фреймів. ВР вказує на поточний кадр, де зберігаються підпрограми-локальні змінні. (Місцеві жителі мають від'ємне відшкодування, а аргументи - за рахунок позитивного компенсації.)

Ідея, що це заважає використовувати ідеально хороший реєстр для оптимізації, викликає питання: коли і де оптимізація насправді варта?

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

Інший код можна скручувати і стискати, щоб позбутися циклів, і це просто не має значення, тому що лічильник програм практично ніколи не існує.

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

Це, безумовно, залежить від компілятора. Я бачив оптимізований код, випромінюваний компіляторами x86, який вільно використовує регістр EBP як реєстр загального призначення. (Я не пригадую, з яким компілятором я це помітив.)

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

Однак у x86 є дуже мало регістрів

Це справедливо лише в тому сенсі, що опкоди можуть адресувати лише 8 регістрів. Сам процесор насправді матиме набагато більше реєстрів, ніж це, і використовувати перейменування реєстру, конвеєрне, спекулятивне виконання та інші мовленнєві слова процесора, щоб обійти цю межу. У Вікіпедії є хороший вступний параграф щодо того, що може зробити процесор x86 для подолання ліміту реєстру: http://en.wikipedia.org/wiki/X86#Current_implementations .

Використання стекових рамок стало неймовірно дешевим у будь-якому обладнанні, навіть віддалено сучасному. Якщо у вас є дешеві кадри стека, то збереження пари регістрів не так важливо. Я впевнений, що швидкий кадр стека проти більшої кількості регістрів був інженерним компромісом, і швидкі кадри стека виграли.

Скільки ви економите, чистий реєстр? Чи варто того?