Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Jan 18, 2020 1:43 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 26 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Mon Sep 19, 2011 1:20 am 
В свое время я был наивным начинающим программистом на ассемблере х86 (впрочем и сейчас не шибко далеко ушел).
Я был в плену двух заблуждений:
1) Стек растет вверх.
На самом деле он растет вниз в сторону уменьшения адресов. Кстати вот тут можно почитать немного http://avtehnika.ru/content/view/477/33/

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

Мои заблуждения проистекали из нередких заголовков в программах для Menuet, например:
Spoiler: Show
Code:
   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: Show
Code:
   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: Show
Code:
   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


Top
   
PostPosted: Mon Sep 19, 2011 1:57 am 
Offline
Kernel Developer
User avatar

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

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


Top
   
PostPosted: Mon Sep 19, 2011 2:05 am 
Значит я не зря сомневался. В любом случае мнение другого человека и специалиста - имеет смысл узнать. Спасибо.


Top
   
PostPosted: Mon Sep 19, 2011 2:09 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1377
FHT: с невыровненным стеком преобразование занимало 110тыс. тактов, а с выравниванием - 71тыс.


Top
   
PostPosted: Mon Sep 19, 2011 4:33 pm 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
Ну и свои пять копеек вставлю -- так сказать, для общего развития. Стек непременно растёт вниз на процессорах архитектуры IA-32, но на других архитектурах правила могут быть другими. Если вдруг придётся работать с чем-то другим, имейте это в виду :)


Top
   
PostPosted: Mon Sep 19, 2011 4:37 pm 
Спасибо КЭП! Я передам по региону!


Top
   
PostPosted: Mon Sep 19, 2011 10:29 pm 
Offline
User avatar

Joined: Mon Jul 25, 2011 6:22 pm
Posts: 93
Не знал, народ, да и предположить не мог, что ЛЮДИ, пишущие на Asm... (не в претензию) могут этого не знать...
Я, конечно, в офф-ициозе здесь не так давно, но всё ж, я за проектом слежу... (???) ...
Ждите мою версию... ...

_________________
Программист не тот, кто постоянно пишет КОД, а тот кто сможет понять чужой КОД!!!


Top
   
PostPosted: Mon Sep 19, 2011 10:38 pm 
Offline
User avatar

Joined: Mon Jul 25, 2011 6:22 pm
Posts: 93
Когда-то, не так давно, один человек представлял свой проект (KolibriOS x64), мне это интересно.
А как всем остальным?

_________________
Программист не тот, кто постоянно пишет КОД, а тот кто сможет понять чужой КОД!!!


Top
   
PostPosted: Mon Sep 19, 2011 10:57 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1377
Artyom wrote:
Не знал, народ, да и предположить не мог, что ЛЮДИ, пишущие на Asm... (не в претензию) могут этого не знать...

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

Ждём-с.


Top
   
PostPosted: Mon Sep 19, 2011 11:11 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Интересно какие потери даёт не выровненный доступ к данным по всему ядру ?


Last edited by Serge on Mon Sep 19, 2011 11:11 pm, edited 1 time in total.

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

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


Top
   
PostPosted: Mon Sep 19, 2011 11:29 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1377
Serge wrote:
Интересно какие потери даёт не выровненный доступ к данным по всему ядру ?

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


Top
   
PostPosted: Tue Sep 20, 2011 11:23 am 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
art_zh wrote:
Но все равно в большинстве случаев издержки байтовой (и битовой) гранулярности с лихвой окупаются компактностью данных и простотой/скоростью кода.


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


Top
   
PostPosted: Tue Sep 20, 2011 7:07 pm 
Offline

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


Top
   
PostPosted: Tue Sep 20, 2011 8:32 pm 
Речь идет о программах работающих в "Protected mode" процессора и работаем мы с 32-х разрядной моделью памяти.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 26 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited