Помощь начинающему ассемблерщику
-
Извини, конечно, но если ТЫ делаешь релизы дистрибутива, то почему ТЫ в первую очередь не проверяешь работоспособность программ и их компилируемость??? Тот макрос, что я привёл здесь, существует в таком виде уже давно, и это отнюдь не моя вина, что в дистрибутиве старая версия.
mike.dld
Да ладно не матькайся.
Ты же мне не сообщаешь, что ты изменил то-то и там-то. Ты вроде вообще нигде про это не пишешь. Как же мне узнать то?
Да ладно не матькайся.
Ты же мне не сообщаешь, что ты изменил то-то и там-то. Ты вроде вообще нигде про это не пишешь. Как же мне узнать то?
Поправьте меня, если я не прав, но я считаю что за всеми изменениями очень сложно отследить. При разработке отдельных модулей, программ часто приходится дописывать или переделывать существующую версию кода (макросов). Я нахожу выход из данной ситуации дастаточно просто:
1) Делаем простой универсальный MACROS.INC, втавляем код универсально подходящий к каждому из приложений. Т.е стандартный скромный набор макросов. Все дальнейшии улучшения или изменения отражаем в специальных макросах идущих к приложению. В дальнейшем усматривается появление скажем MACROS2.INC в котором будет собрана дополнительный код макросов, необходимый для разработки определенного круга приложений. Я хочу сказать, что появление универсальных кусков кода должно быть проверено большим количеством прораммистов и временем, должна оставаться приемственность.
2) Обязанности по разработке дистрибутива должно быть разделено между несколькими людьми. А именно:
а) Человек разбирается с ядром ОС, по этому все изменения и предложения касающиеся ядра он берет в свои руки и занимается этим.
б) Человек занимается определеной направленностью скажем пишет что то из ПО к ОС -> следовательно все баги и предложния уходят к нему.
....... и т.д. Тут можно продолжить ..... Мысль моя думаю будет ясна...
При достаточном изменении и дополнении кода решаем выпустить очередной дистрибутив
Частично я думаю реализованно все близко к тому что я написал, но все же я думаю это внесет ясность
***********************
К примеру, захотелось мне улучшить MFAR от mike.dld, я пишу фунции, дорабатываю код, затем списываюсь с mike.dld, обсужаю детали, находим ошибки и т.д. В итоге Получаем улучшенную версию MFAR, которая необходима многим людям.
1) Делаем простой универсальный MACROS.INC, втавляем код универсально подходящий к каждому из приложений. Т.е стандартный скромный набор макросов. Все дальнейшии улучшения или изменения отражаем в специальных макросах идущих к приложению. В дальнейшем усматривается появление скажем MACROS2.INC в котором будет собрана дополнительный код макросов, необходимый для разработки определенного круга приложений. Я хочу сказать, что появление универсальных кусков кода должно быть проверено большим количеством прораммистов и временем, должна оставаться приемственность.
2) Обязанности по разработке дистрибутива должно быть разделено между несколькими людьми. А именно:
а) Человек разбирается с ядром ОС, по этому все изменения и предложения касающиеся ядра он берет в свои руки и занимается этим.
б) Человек занимается определеной направленностью скажем пишет что то из ПО к ОС -> следовательно все баги и предложния уходят к нему.
....... и т.д. Тут можно продолжить ..... Мысль моя думаю будет ясна...
При достаточном изменении и дополнении кода решаем выпустить очередной дистрибутив
Частично я думаю реализованно все близко к тому что я написал, но все же я думаю это внесет ясность
***********************
К примеру, захотелось мне улучшить MFAR от mike.dld, я пишу фунции, дорабатываю код, затем списываюсь с mike.dld, обсужаю детали, находим ошибки и т.д. В итоге Получаем улучшенную версию MFAR, которая необходима многим людям.
могу сказать что использование команды xchg не оптимально. Приведу вырезку из рассылки Калашникова выпуск 18, 22
Code: Select all
Это твой вариант... (14 строк)
========= из файла display asm Procedure Get_linear ===========
push ax ;сохраним все используемые регистры
push bx
push dx
shl dl, 1 ;математика: умножаем DL на 2 (DL=DL*2)...
mov al, dh ;в AL - ряд,
mov bl, 160 ;который нужно умножить на 160
mul bl ;умножаем: AL(ряд)*160; результат --- в AX
mov di,ax ;результат умножения в DI
xor dh,dh ;аннулируем DH
add di,dx ;теперь в DI линейный адрес в видеобуфере...
pop dx ;восстанавливаем регистры...
pop bx
pop ax
ret
А вот мой вариант (12 строк):
================================
push ax
push dx
xor ax, ax
xchg dh, al ; Имеем в dx =dl, а в ax = dh
mov di, ax
shl ax, 6 ; dh*64
shl di, 4 ; dh*16
add di, ax
add di, dx
shl di, 1 ; *2
pop dx
pop ax
ret
==================
То что мой вариант короче на 2 строки - это мелочи. Не в этом соль. Он быстрее, так как я использую команду сдвига (shl), а не умножения (mul). И регистров использует меньше (только ax).
Тут еще вот какой момент:
Ты используешь 160, т.е. уже умножил ширину экрана на 2. Но ведь ты потом все равно умножаешь на 2 dl. И почему только сдвиги:
Линейный адрес = (COL*80+RAW)*2
Отсюда:
Линейный адрес = (COL*64+COL*16+RAW)*2
Или:
Линейный адрес = ((COL shl 6) + (COL shl 4) + RAW) shl 1
Good luck. Slava V.
Здравствуйте, Олег!
Ваш эксперт Slava V. совершил очень существенную ошибку в своем оптимизированном варианте - это использование инструкции Xchg. Эта инструкция на время своего выполнения захватывает системную шину памяти (префикс Lock), что может привести (и приводит) к существенным задержкам.
В связи с этим предлагаю свой вариант:
_________________
Count_dx proc
push ax
push dx
mov al, dh
cbw ;ax=dh
xor dh, dh
mov di,ax
shl ax,6
shl di,4
add di,ax
add di,dx
shl di,1
pop dx
pop ax
Count_dx endp
_____________
Пришлось написать небольшую программку на Паскале, с помощью которой можно сравнить скорости работы различных вариантов этого фрагмента. Вот ссылка http://akp.nm.ru/get_linear_test.zip (1,8Kb).
Вот такие результаты я получил на своем Celeron 433 (тестирование проводил под Win 98):
исходный вариант (т.е. тот, который был опубликован в рассылке - прим. О.К.) - 1,713 мс (*)
вариант Slava V. - 2,393 мс
мой вариант - 1,540 мс
* - вот вам и медленная инструкции mul :) Ядра 6-го семейства процессоров от Intel (кстати, и от AMD тоже) содержат существенно ускоренные инструкции умножения, деления в отличии от предыдущих семейств. Вот так :)
По поводу результатов выполнения на других процах конкретных результатов привести не могу, т.к. нет возможности.
Алексей.
Johnny B
Ты сам же обнаружил недостаток своего кода. Желательно, чтобы код был универсален.
А вообще использование аналогичного цикла без строковых команд, хоть и занимает больший размер, но выполняется быстрей. Насколько я знаю по литературе - строковые команды это по сути подпрограммы, которые процессор заменяет при исполнении кода на кучу более простых в сумме образующих эту команду. Конечно, это не особенно актуально для современных процессоров, но применение строковых команд еще менее актуально для объемов сегодняшней памяти.
Оптимизация конечно хорошее дело, лишь бы оно не тормозило разработку приложения для самого программиста.
<Lrz>
Насколько я знаю, Калашников хоть и умный мужик, но он тоже достаточно часто ошибается. Юров правда тоже бывает с ошибками, хотя я им пользуюсь.
А уж сам то я как часто ошибаюсь...
Ты сам же обнаружил недостаток своего кода. Желательно, чтобы код был универсален.
А вообще использование аналогичного цикла без строковых команд, хоть и занимает больший размер, но выполняется быстрей. Насколько я знаю по литературе - строковые команды это по сути подпрограммы, которые процессор заменяет при исполнении кода на кучу более простых в сумме образующих эту команду. Конечно, это не особенно актуально для современных процессоров, но применение строковых команд еще менее актуально для объемов сегодняшней памяти.
Оптимизация конечно хорошее дело, лишь бы оно не тормозило разработку приложения для самого программиста.
<Lrz>
Насколько я знаю, Калашников хоть и умный мужик, но он тоже достаточно часто ошибается. Юров правда тоже бывает с ошибками, хотя я им пользуюсь.
А уж сам то я как часто ошибаюсь...
я думаю, что вопрос по теме... дайте ссылки пожалста на какие-нить учебники по фасму... желательно, что-б по каждой команде описание было! Уже сколько пытаюсь чё-нить напрограммировать... всё на создании окна программы останавливается (хотя уже есть определённые достижения)))
подойдет любой учебник по ассемблеру.(они мало чем отличаются). Я использовал учебник Зубкова "Assembler для DOS,Windows и UNIX"
http://www.bookshelf.ru/modules.php?nam ... iles_id=11
http://www.bookshelf.ru/modules.php?nam ... iles_id=11
AqwAS
http://asm.shadrinsk.net/
Я лично пользуюсь Юровым, но у него только команды 386 процессора, но зато как расписано. Нигде больше таких подробных док не встречал.
Есть еще неплохие доку у Зубкова.
Также по ссылке рекомендую скачать pentium.zip с сайт по ссылке выше, в нем краткое описание всех команд Pentium.
Ну а самые подробные доку конечно у самой Intel, правда, все на английском.
http://asm.shadrinsk.net/
Я лично пользуюсь Юровым, но у него только команды 386 процессора, но зато как расписано. Нигде больше таких подробных док не встречал.
Есть еще неплохие доку у Зубкова.
Также по ссылке рекомендую скачать pentium.zip с сайт по ссылке выше, в нем краткое описание всех команд Pentium.
Ну а самые подробные доку конечно у самой Intel, правда, все на английском.
Подскажите пожалста кто-нибудь вот по какому поводу:
каким образом можно в программе сделать базу данных, состоящую из строк, например:
apple - яблоко
beer - ... и т.п.
и организовать поиск по ней... чтобы ввести напр. apple или яблоко и выводилась нужная строка?
каким образом можно в программе сделать базу данных, состоящую из строк, например:
apple - яблоко
beer - ... и т.п.
и организовать поиск по ней... чтобы ввести напр. apple или яблоко и выводилась нужная строка?
Отсортировать по первому и второму признакам (сортировать только индексы конечно) и дальше использовать бинарный поиск. Если нужно быстро удалять и добавлять элементы, то тут нужно сбалансированное (в крайнем случае декартово)дерево.
Who is online
Users browsing this forum: No registered users and 7 guests