Работа со стеком

Assembler programming questions
  • Mario wrote:Много раз встречаю, что указатель стека устанавливается не на ровную границу, а на границу и -1 байт. Казалось бы область для стека выровнена на границу 4 байта и это идеально, но почему же люди сдвигают на 1 байт назад? Может есть какая-то особая уличная магия и я ее не знаю? Или есть в тонкостях документации что-либо по этому поводу. Я прошу тех кто в курсе прояснить ситуацию.
    Невыровненный esp - грубая ошибка, встречающаяся во многих программах.
    Работать такая программа конечно будет, но производительность при этом очень заметно падает. Кстати, и энергопотребление - тоже (потому что требуется один лишний цикл шины для каждого push/pop, call/ret и т.п.)
  • Значит я не зря сомневался. В любом случае мнение другого человека и специалиста - имеет смысл узнать. Спасибо.
  • FHT: с невыровненным стеком преобразование занимало 110тыс. тактов, а с выравниванием - 71тыс.
  • Ну и свои пять копеек вставлю -- так сказать, для общего развития. Стек непременно растёт вниз на процессорах архитектуры IA-32, но на других архитектурах правила могут быть другими. Если вдруг придётся работать с чем-то другим, имейте это в виду :)
  • Спасибо КЭП! Я передам по региону!
  • Не знал, народ, да и предположить не мог, что ЛЮДИ, пишущие на Asm... (не в претензию) могут этого не знать...
    Я, конечно, в офф-ициозе здесь не так давно, но всё ж, я за проектом слежу... (???) ...
    Ждите мою версию... ...
    Программист не тот, кто постоянно пишет КОД, а тот кто сможет понять чужой КОД!!!
  • Когда-то, не так давно, один человек представлял свой проект (KolibriOS x64), мне это интересно.
    А как всем остальным?
    Программист не тот, кто постоянно пишет КОД, а тот кто сможет понять чужой КОД!!!
  • Artyom wrote:Не знал, народ, да и предположить не мог, что ЛЮДИ, пишущие на Asm... (не в претензию) могут этого не знать...
    Зевки и ляпы бывают у всех - не боги горшки обжигают. Кто-то поставил esp на 1FFFF - и понеслась копипаста.
    А вообще на асме работать легко и удобно, особенно в Колибре.
    Ждите мою версию... .
    Ждём-с.
  • Интересно какие потери даёт не выровненный доступ к данным по всему ядру ?
    Last edited by Serge on Mon Sep 19, 2011 11:11 pm, edited 1 time in total.
  • Artyom wrote:Не знал, народ, да и предположить не мог, что ЛЮДИ, пишущие на Asm... (не в претензию) могут этого не знать...
    Очевидные для одних вещи не всегда очевидны для других. Это не повод кого-либо обвинять в чем-либо.
  • Serge wrote:Интересно какие потери даёт не выровненный доступ к данным по всему ядру ?
    Не так уж его и много осталось.
    Явные косяки почти все выправили.
    Осталась экранная карта, карта страниц, еще кое-что по мелочи.
    Но все равно в большинстве случаев издержки байтовой (и битовой) гранулярности с лихвой окупаются компактностью данных и простотой/скоростью кода.
  • art_zh wrote:Но все равно в большинстве случаев издержки байтовой (и битовой) гранулярности с лихвой окупаются компактностью данных и простотой/скоростью кода.
    Угу, поскольку невыровненные доступы вызывают серьёзные тормоза только в случае, если обращение действительно идёт к памяти. Если всё нужное уже лежит в кэше, тормозов нет или они небольшие (тут уж как кэш устроен и на каком именно его уровне данные находятся). Поскольку компактность позволяет более эффективно использовать кэш, она нередко (но не всегда, конечно) даёт больший выигрыш, чем потери на невыровненных доступах. Так что выравнивать надо, но без фанатизма, принимая во внимание и другие факторы.
  • Часто приходилось встречать, когда для 16-разрядных сегментов (обычно реального режима) устанавливают вершину стека 0FFFFh, боясь использовать 0. Возможно, использование указателей стека типа xxxFFFh вызвано этим же. Кстати, в моем "упрощенном исполняемом формате" нет поля для явного хранения указателя стека (только размеры). Это позволяет свободно располагать стек первичного прикладного потока в конце прикладного адресного пространства вне зависимости от размера пространства. Стек в "образ" не входит.
  • Речь идет о программах работающих в "Protected mode" процессора и работаем мы с 32-х разрядной моделью памяти.
  • Who is online

    Users browsing this forum: No registered users and 1 guest