Тасм32 и ООП

Привет всем! С наступающим! У меня есть возможность добавить новые функции к Тасму. Присылайте свои замечания

и пожелания на limon-5@yandex.ru или на етот тред. Постараюсь включить в нов. версию Тасма. Сам я направлен на интеграцию с HLL-компиляторами. Базовая поддержка классов на уровня компилера, высокоуровневые выражения и директивы. А пока пишу ассемблер 4 пня.

Всего наилучшего.

 

Можно подробнее?

Ты делаешь front-end к tasm, или у тебя есть его сорцы, которые ты дорабатываешь?

 

Чиста прибиваю к бинарнику собственный парсер. Но нуно сначала рипануть из его кода его собственный. Вообщем, проектирвание етого асма на меня произвело впечатление, много интересных решений. Но , что не понравилось, не соблюден принцип черного ящика, То есть парсер работает и при компиляции и при листинге, ит.п. После добавления собственного парсера, ООП-интеграция. Ща вообщем с головой в этом.

 

Ты его в IDA что-ли засунул и ковыряешь ?! Ну, круто

только не проще ли взять ассемблер в сорцах, например fasm, если хочешь режим ideal tasm, или wasm (watcom assembler), если нужен синтаксис как в masm.

Хотя IMHO всё это можно (ещё проще) реализовать в отдельном модуле, который будет генерировать сорцы для back-end ассемблера, как, например, это делает HLA.

Плохо понимаю целесообразность этого - tasm не делает coff, толку от его omf объектников мало, их ни счем не слинкуешь :-(

Или, если ты всё равно пишешь сам кодогенератор для 4 пня (хотя видимо ты дорабатываешь готовый), и собераешься делать ещё и парсер, то тебе останется только препроцессор написать - и будет собственный компилятор

 

S_T_A_S_

> tasm не делает coff



Гы, а fasm не делает omf - иногда это очень нужно

 

Asterix



Ну если кто-то будет делать киген на дельфи, то можно и без mod обойтись: mp3 музыку влепить - относительный размер не намного увеличится ))))

 

S_T_A_S_

Да ладно тебе, на дельфи получаются ооочень маленькие проги..

Вот например, в аттаче, использовались всего три модуля:

Windows, Messages, SysUtils, так что никакого гемора при работе с fpu на asm'е - быстро и сердито



Почему бы ей не быть кигеном?

_905046816__Calculate.rar

 

Ну если 50к - маленькая..



Для прог такого класса потолок - 2кб (потому что ресурсы).



И гемора с фпу я никогда не испытывал почему-то

 

S_T_A_S_

"Хотя IMHO всё это можно (ещё проще) реализовать в отдельном модуле, который будет генерировать сорцы для back-end ассемблера, как, например, это делает HLA."



Мой подход к ООП.

 

AsmGuru62



У этого метода есть один недостаток (который, впрочем имеют все современные компиляторы для x86) - нельзя указать, что некоторый блок кода должен иметь размер, кратный XX байт (делается путём увеличения размера некоторых инструкций за счёт альтернативного кодирования: SIB, ModR/M, imm8 - imm32). Это может быть полезно для оптимизации циклов по скорости. Для решения необходимо совмещение fron-end и back-end в единое целое. При этом, сам back-end должен быть принципиально новым ассемблером.

 

А подробнее можно? Про оптимизацию?

Как раз пишу генератор FASM кода.

Я прочитал Intel Manual по оптимизации от корки до корки, но не встретил подобного.

Только метки в быстром цикле надо выравнивать, так для этого есть директива ALIGN.

 

AsmGuru62

Странно...



По-моему The Svin и S_T_A_S_ весь форум прожужжали насчёт этого



Да речь именно об align. А как делать align? В общем случае вставкой nop-ов. А nop-ы - это лишние телодвижения. Однако, от них в большинстве случаев можно полностью избавиться, если применять "избыточное" кодирование методов адресации. Например для "чисто базовой" адресации существует семь способов кодирования (плюс ещё три, если позволить себе некоторые вольности) которые дают четыре различные дополнительные длины команды.



S_T_A_S_ даже недавно выписывал эти семь способов...

Не могу только найти где...

 

Не понимаю - зачем NOPs?

Директива ALIGN есть везде:

Код (Text):

1. mov ecx, counter
2. mov edx, 1
3.  
4. align 32
5. .loop_begins_here:
6. ...
7. sub ecx, edx
8. jnz .loop_begins_here

 

AsmGuru62

Так нопы тебе и не надо, генерируй align, а как он будет реализован - это дело компилятора (т.е. фасма), потом получится что-то вроде:

Код (Text):

1. align 16 00402470 |.  8B0D 00104000 |MOV ECX,[401000]
2.          00402476 |.  BA 01000000   |MOV EDX,1
3.          0040247B |.  90            |NOP
4. align 4  0040247C |.  90            |NOP
5.          0040247D |.  90            |NOP
6.          0040247E |.  90            |NOP
7.          0040247F |.  90            |NOP
8. align 32 00402480 |>  29D1          |/SUB ECX,EDX
9.          00402482 |.^ 75 FC         |\JNZ SHORT 00402480

Просто нопы забирают немного процессорного времени, а если в этом случае заопкодировать MOV ECX и MOV EDX на 5 байт больше, то этого могло бы и не произойти, но это все есс-но для конкретно-камневых случаев и IDE (ты ведь его делаешь?) тут никаким боком участвовать не должно (хотя возможна интеллектуальность на уровне подсказок для оптимизации

 

Директива align есть везде, но она очень даже разная.

Обычно генерируются однобайтные nop'ы (т.е xchg eax, eax).

Но в случаях, когда этих однобайтных nop'ов несколько лучше делать многобайтные:

Код (Text):

1.  
2. 8D 00                 lea     eax, [eax]
3. 8D 04 20              lea     eax, [eax]
4. 8D 44 20 00           lea     eax, [eax]
5. 8D 80 00 00 00 00     lea     eax, [eax]
6. 8D 04 05 00 00 00 00  lea     eax, [eax]
7.  

А ещё лучше, обходиться без заполнителей, если это возможно (не совсем удачный пример, но смысл виден)

Код (Text):

1.  
2. 00402470 3E 3E 8B 0C 25 00 10 40 00  mov     ecx, [401000]
3. 00402479 3E 67 BA 01 00 00 00        mov     edx, 1
4. 00402480 2B D1                       sub     edx, ecx
5. 00402482 75 FC                       jnz     00402480
6.  

 

Было дело. Ковырнул я иго, значимые местечка. Потом взбесило , что как-то мудрено идет работа с чтением исходников, запутался в трех соснах. И сел за свой препроцессор. В принципе, ничего сложного. Хотя он больше похож по синтаксису на сишный. Асмовый в последнее время мне стал нравится все меньше и меньше. Да, у Асма в препроцессоре есть одна мощная фишка, директива макро, остальное - смешно как-то. Надеюсь, в скором времени выпустить тасм32 в плавание. Эдак, через 2 недельки.

Мотивация ковыряния тасма32. Чиста немного мазохизму и садизму, далее есть желание написать декомпилятор сишных и приплюснутых прог от Бормана и Мелкого. Ну подумал я, если вручную не смогу дизасмить более - менее толстую прожку, то какой-то толк браться за декомпилер. Ну и сбацал. А тасм32 скомпилен самим сабой. И ковырять его - сплашное удовольствие - исходный код угадывается с полпинка, наверное, при его создании использовали туеву кучу макросов и всякого ишшо барахла. Код ну прям как Hll-ный.

 

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

Абстрагируясь, скажу, что асм нового поколения - это си

приземленный на определенную платформу и усе.

Пока фасм более менее успешно идет в этом направлении.

Но стиль исходников просто ужасен. На мой взгляд. Ни одной структуры, дефайнов.

 

Я работаю над чем-то похожим.

ООП ассемблер с IDE.

Что-то в стиле Randall Hyde, но более удобоваримое.

 

Прекрасно, если есть возможность где-нить утянуть и посмотреть на ваши труды, еще лучше.



Сейчас у меня гамлетовская ситуация. Или учеба ( тока что восстановился на 5 курс), или проект.

Я подозреваю, что полноценный декомпилятор с С давно создан. Как я вижу, сложного в этом ничего нет.

Потому компилятор мой ориентирован на работу в тесной связке с декомпилятором.

 

В задумках сделать упор на оптимизатор.

например, кульнаые хацкеры кодят на масме с hll-выражениями, а в екзешнике палучается отвратительгое дерьмо. Так как челу в лом оптимизировать например свитчи.

И идет там километр if..else if.

Но так как в компилере будет смешанная грамматика ( си и асм), придется свяать накрепко компилер с дизасмером/декомпилером.