Board.KolibriOS.org

В свое время я был наивным начинающим программистом на ассемблере х86 (впрочем и сейчас не шибко далеко ушел).
Я был в плену двух заблуждений:
1) Стек растет вверх.
На самом деле он растет вниз в сторону уменьшения адресов. Кстати вот тут можно почитать немного http://avtehnika.ru/content/view/477/33/

2) Стек можно размещать только в конце программы.
П.2 логически проистекал из п.1
На самом деле стек можно размещать где угодно в программах Колибри.

Мои заблуждения проистекали из нередких заголовков в программах для Menuet, например:

Spoiler:

Code: Select all

	use32
	org 0x0
	db 'MENUET01'	; 8 byte id
	dd 0x01		; header version
	dd START	; start of code
	dd I_END	; size of image
	dd 0x1000000	; memory for app
	dd 0x7FFFFFF	; esp
	dd 0x0,0x0	; I_Param , I_Icon

Зачем было выделять программе использующей менее 4 Кб памяти целых 16 Мб (ШЕСТНАДЦАТЬ!) и ставить указатель стека в середину выделенной памяти, для меня так и осталось загадкой. Впрочем оставим это на совести оригинального автора, имевшего свое особое видение - как надо разрабатывать программы.

Сейчас же меня интересует другой вопрос:
Много раз встречаю, что указатель стека устанавливается не на ровную границу, а на границу и -1 байт. Казалось бы область для стека выровнена на границу 4 байта и это идеально, но почему же люди сдвигают на 1 байт назад? Может есть какая-то особая уличная магия и я ее не знаю? Или есть в тонкостях документации что-либо по этому поводу. Я прошу тех кто в курсе прояснить ситуацию.

Я не наблюдаю никакой падучести программы при например такой установке:

Spoiler:

Code: Select all

	use32
	org 0x0
	db 'MENUET01'	; 8 byte id
	dd 0x01		; header version
	dd START	; start of code
	dd I_END	; size of image
	dd 0x20000	; memory for app
	dd 0x20000	; esp
	dd 0x0,0x0	; I_Param , I_Icon

Хотя явное указания адресов мешает сопровождать и писать программу, так что следующее указание лучше:

Spoiler:

Code: Select all

	use32
	org 0x0
	db 'MENUET01'	; 8 byte id
	dd 0x01		; header version
	dd START	; start of code
	dd IM_END	; size of image
	dd I_END	; memory for app
	dd stacktop	; esp
	dd temp_area	; I_Param
	dd path		; APPLICATION PACH

Mario wrote:Много раз встречаю, что указатель стека устанавливается не на ровную границу, а на границу и -1 байт. Казалось бы область для стека выровнена на границу 4 байта и это идеально, но почему же люди сдвигают на 1 байт назад? Может есть какая-то особая уличная магия и я ее не знаю? Или есть в тонкостях документации что-либо по этому поводу. Я прошу тех кто в курсе прояснить ситуацию.

Невыровненный esp - грубая ошибка, встречающаяся во многих программах.
Работать такая программа конечно будет, но производительность при этом очень заметно падает. Кстати, и энергопотребление - тоже (потому что требуется один лишний цикл шины для каждого push/pop, call/ret и т.п.)

Значит я не зря сомневался. В любом случае мнение другого человека и специалиста - имеет смысл узнать. Спасибо.

FHT: с невыровненным стеком преобразование занимало 110тыс. тактов, а с выравниванием - 71тыс.

Ну и свои пять копеек вставлю -- так сказать, для общего развития. Стек непременно растёт вниз на процессорах архитектуры IA-32, но на других архитектурах правила могут быть другими. Если вдруг придётся работать с чем-то другим, имейте это в виду

Спасибо КЭП! Я передам по региону!

Не знал, народ, да и предположить не мог, что ЛЮДИ, пишущие на Asm... (не в претензию) могут этого не знать...
Я, конечно, в офф-ициозе здесь не так давно, но всё ж, я за проектом слежу... (???) ...
Ждите мою версию... ...

Когда-то, не так давно, один человек представлял свой проект (KolibriOS x64), мне это интересно.
А как всем остальным?

Artyom wrote:Не знал, народ, да и предположить не мог, что ЛЮДИ, пишущие на Asm... (не в претензию) могут этого не знать...

Зевки и ляпы бывают у всех - не боги горшки обжигают. Кто-то поставил esp на 1FFFF - и понеслась копипаста.
А вообще на асме работать легко и удобно, особенно в Колибре.

Ждите мою версию... .

Ждём-с.

Интересно какие потери даёт не выровненный доступ к данным по всему ядру ?

Artyom wrote:Не знал, народ, да и предположить не мог, что ЛЮДИ, пишущие на Asm... (не в претензию) могут этого не знать...

Очевидные для одних вещи не всегда очевидны для других. Это не повод кого-либо обвинять в чем-либо.

Serge wrote:Интересно какие потери даёт не выровненный доступ к данным по всему ядру ?

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

art_zh wrote:Но все равно в большинстве случаев издержки байтовой (и битовой) гранулярности с лихвой окупаются компактностью данных и простотой/скоростью кода.

Угу, поскольку невыровненные доступы вызывают серьёзные тормоза только в случае, если обращение действительно идёт к памяти. Если всё нужное уже лежит в кэше, тормозов нет или они небольшие (тут уж как кэш устроен и на каком именно его уровне данные находятся). Поскольку компактность позволяет более эффективно использовать кэш, она нередко (но не всегда, конечно) даёт больший выигрыш, чем потери на невыровненных доступах. Так что выравнивать надо, но без фанатизма, принимая во внимание и другие факторы.

Часто приходилось встречать, когда для 16-разрядных сегментов (обычно реального режима) устанавливают вершину стека 0FFFFh, боясь использовать 0. Возможно, использование указателей стека типа xxxFFFh вызвано этим же. Кстати, в моем "упрощенном исполняемом формате" нет поля для явного хранения указателя стека (только размеры). Это позволяет свободно располагать стек первичного прикладного потока в конце прикладного адресного пространства вне зависимости от размера пространства. Стек в "образ" не входит.

Речь идет о программах работающих в "Protected mode" процессора и работаем мы с 32-х разрядной моделью памяти.