Masm, nasm, fasm, hla, краткий ликбез?

FASM: Удобная возможность залезть во все внутренности исполнимого файла конечно круто!
Но сильно ли нужно это когда пишешь программы для GUI WIN32 ?

Пресловутая скорострельность FASM результат не столько алгоритма, сколько ограниченности вложенных файлов!

Запустите в MASM 32 v9:
.386
.model flat,stdcall
option casemap :none ; case sensitive
NULL equ 0
MB_OK equ 0h
ExitProcess PROTO WORD
MessageBoxA PROTO WORD,WORD,WORD,WORD
MessageBox equ <MessageBoxA>
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
.data
MsgBoxCaption db "Я изучаю ассемблер!",0
MsgBoxText db "Здравствуй, мир!",0
.code
start:
invoke MessageBox, NULL, addr MsgBoxText, addr MsgBoxCaption, MB_OK
invoke ExitProcess, NULL
end start
и убедитесь, что он тоже летает будь здоров!

Но по моему гораздо приятнее написать в начале программы:
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
...
и оптом получить весь комплект API с их константами (пусть лишнюю пару сек. компилируется (это на моём-то антикварном PII 266МГц !!!)), чем долго и нудно вручную перечислять КАЖДУЮ внешнюю функцию в отдельной строке, мучительно вспоминая, а использовал я её в этой программе или нет?, или сначала использовал, а потом выкинул?

Кстати MASM 32 в отличие от TASM и FASM при оптовом подключении API прототипов слинкует только те, которые были реально задействованы в программе!

Сильно разрекламированные возможности MACRO в FASM в подробностях пока не изучал, но при беглом взгляде на них чего-либо принципиально не реализуемого на MACRO в MASM 32 не обнаружил.

 

Собственно написано в MASM 32, но принципиальных противопоказаний для переноса в другие ассемблеры не вижу, ну если только что нибудь по мелочи, обработка знака тоже добавляется элементарно.
.data
i_1000000000 dd 1000000000
i_100000000 dd 100000000
i_10000000 dd 10000000
i_1000000 dd 1000000
i_100000 dd 100000
i_10000 dd 10000
i_1000 dd 1000
i_100 dd 100
i_10 dd 10
i_1 dd 1
.code
;-------------------------------------------------------------------------------------
; Беззнаковое преобразование двойного слова в строку без ведущих нулей
; возвращает EDI = адрес следующего символа в строке
DWORD_to_STR_non_Begin_Zero_proc PROC ; EAX - преобразуемое число
.REPEAT ; Цикл отсеивания ведущих нулей ; EDI - адрес строки
xor EDX, EDX ; ECX - код: DWORD = 9; WORD = 4; BYTE = 2
mov EBX, [ESI] ; ESI - код: DWORD = offset i_1000000000
div EBX ; разделить на i_10... ; WORD = offset i_10000
or EAX, EAX ; BYTE = offset i_100
.BREAK .IF !ZERO? ; Выход если найден не нулевой символ
add ESI, 4 ; перейти к следующему i_10...
mov EAX, EDX ; остаток от деления использовать дальше
.UNTILCXZ ; Цикл по ECX
cld ; увеличение ESI, EDI
add ESI, 4 ; перейти к следующему i_10...
add EAX, '0'
STOSB ; [EDI] = AL, inc EDI - занести символ в строку
or ECX, ECX
.IF !ZERO?
.REPEAT ; Цикл преобразования
mov EAX, EDX ; остаток от деления использовать дальше
xor EDX, EDX
mov EBX, [ESI]
div EBX ; разделить на i_10...
add ESI, 4 ; перейти к следующему i_10...
add EAX, '0'
STOSB ; [EDI] = AL, inc EDI - занести символ в строку
.UNTILCXZ ; Цикл по ECX
.ENDIF
ret
DWORD_to_STR_non_Begin_Zero_proc ENDP

 

Y_Mur

В фасме тоже можно *оптом* импортировать.
Фасм тоже слинкует только те что реально задействованы (во всяком случае при использовании оптовых инклуд).
Вот что мне бы хотелось поменять в фасме, это чтобы квадратные скобки использовались в обратном смысле, тогда их бы пришлось реже ставить и код выглядил бы еще проще. Это мое мнение.
За алгоритм дворда в интегер спасибо : )

 

Y_Mur

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

Производительность у этого кода почти нулевая (div 10, stosb, loop) и размер тоже не впечатляет. В общем, выдержано в стиле масмовой стандартной либы

 

Перешел с масм на фасм. Вначале думал, что синтаксис просто уродский, а сейчас просто блаженствую =)
Реально гибкая система написания макросов. Если очень захотеть, то мож даже сделать парсер *.h файлов без всяких inc и проч, но как-то руки не доходят =)

 

Ничего подобного. Реализуй в масм (если сможешь ) MD5, SHA512 на макросах и сравним скорость компиляции?

 

Y_Mur

Есть кроссассемблерный проект, который можно собирать любым из следующих асмов: masm, tasm, nasm, fasm. Инклуды не используются вообще. Макросов в проекте нет. Быстрее всего имидж собирает фасм (почти мгновенно). На втором месте насм (2-3 секунды). Бронза достаётся тасму (3-4 секунды). Масм: 4-5 сек. Могу посчитать ещё и миллисекунды, если важна точность.

 

лучше назвать машину, на которой собиралось, сколько там памяти, порядок собирания (т.е. какой компилятор первый и т.д.), кол-во строк в проекте.
Я не оспариваю скорости фасма, но если он остальные опрежает на 10-15%, то никакого предмета для гордости я не вижу, а то ярые фасмопоклонники практически только этим и аргументируют "крутость" фасма.

 

masquer

Машин несколько. Последний раз сравнивал на P4 - 2.8GHz / 512 Mb DDR2. Пробовал и на более слабых (предел тормознутости - qemu, но на нём я могу сравнить только фасм vs. насм), и на более сильных конфигурациях.

На результатах не сказывается.

3515 + 1158 + ещё пара мелких файлов размером меньше 1000 строк каждый.

Для этого удобнее привести точные результаты по миллисекундомеру:

fasm: от менее 50ms до 420ms
masm: от 2300ms до 5100ms

Запускал 5 раз.

 

Не надо, не только этим

 

А какие собственно возражения против stosb? когда результат нужно встроить в произвольную текстовую строку (т.е. выравниванием и не пахнет), а количество цифр результата в общем случае не крантно 4м?

 

Y_Mur
речь идёт о скорости
у упомянутых Quantum'ом команд есть более быстрые аналоги

 

В своё время писал и под Тасм и под Масм (кстати не так давно) НО! перейдя на Фасм и почувствовав его РЕАЛЬНУЮ мощь - уфф скажу я вам... о таком я и не мечтал - контороль над генерируемыми исполняемыми модулями полный. А чего стоит одно только "безсекционное" программирование в фасме! ну когда он может слепить всё в одну .flat секцию - и импорт и ресурсы и данные и код и бог знает что еще туда можно позаписать и всё ведь корректно работает при всех при этих пертрубациях) Да ещё когда сам где хочешь секцию вставляешь - хошь ресурсы тебе будет первая секция, хошь импорт - так перемешать можно! ) Блаженствую!
удаляёте если посчитаете оффтопом...

 

имхо - _ничего_ это не стоит
да, в масме это командной строкой решается, что более гибко в данном случае.

 

здается мне что в фасме можно сделать односекционный файл даже при наличии в нем
ресурсов, разместив ресурсы в начале секции и обозвав секцию .rsrc, но я не пробовал
если честно %), а вот masm это сделать не даст ни при каких обстоятельствах, если
не прав то поправьте =)

 

Y_Mur

В данном случае stosb на фоне div это фигня, но вообще stosb используется только ради экономии размера в ущерб скорости, т.к. выполняется дольше чем эквивалентный набор простых операций.
Но вот как ты додумался "отсеивание ведущих нулей" делать через div, вместо cmp - просто шедевр антиоптимизации и наглядный аргумент к незапамятной дискуссии с xlinuks о якобы врожденной быстроте асма и тупости ЯВУ-компиляторов ))))

 

таак.. это уже камень в мой огород! причем тут ява? она всегда будет работать медленнее изза динамической компиляции, если тебе это чтото говорит.

 

xlinuks
Ты в каком селе учился ))
Я не о Жабе, а о ЯВУ = Язык Высокого Уровня, он же HLL = High Level Language, "если тебе это что!то говорит" ))

Ладно, шутки в сторону Если ты еще не определился с dwtoa, то слухай сюда
1) в NT можно юзать _itoa из ntdll.dll (там много еще чего полезного можно найти , хотя там используется деление через div - не слишком быстро, зато компактно
2) в масме использован вариант с заменой деления умножением. За обновлениями не слежу, но масмовский исходник dwtoa был с глюком (см.тему m32lib bug: dwtoa) - из-за мелочной экономии одной инструкции был выбран слишком маленький множитель = 2^32/10 (нужно брать по максимуму 2^35/10 = 0CCCCCCCDh) - в результате числа более 40000004h выводились с ошибкой - лишний аргУ'мент "в пользу" доморощенных либ В той же теме есть рабочий вариант crestа (хотя я бы и его чуточку подправил для исключения лишних jcc - могу запостить для коллекции
3) "суперскоростной", но жутко длинный вариант есть в мануале по оптимизации от AMD

 

с русским слэнгом у меня не так хорошо, еслиб сказал HLL яб понял, за типы о парсере спасибо.

 

а это не сленг, это жаргон