Битва трансляторов

Крис Касперски

Хакер, номер #092, стр. 092-118-1

ASM-трансляторы: что такое хорошо и что такое плохо

Проблема выбора «единственного правильного» ассемблерного транслятора мучает не только начинающих, но и профессиональных программистов. У каждого продукта есть своя когорта поклонников, и спор о преимуществах/недостатках рискует превратиться в священные войны с выносом тел погибших. На форумах такие дискуссии лучше не разводить и вещать в одностороннем порядке, как я, собственно, и поступил, сравнив MASM, TASM, FASM, NASM, YASM и некоторые другие ассемблеры по всему спектру критериев, значимость которых каждый должен оценивать сам.

Основополагающие критерии

Существует ряд критериев, существенных для всех категорий программистов. Начнем с генерации отладочной информации, без которой отладка программы сложнее, чем «hello, word», превращается в настоящую пытку. Но если формат отладочной информации — это задний двор транслятора, то формат выходных файлов — это его лицо. Непосвященные только пожмут плечами. Какой там формат? Обыкновенный obj, из которого с помощью линкера можно изготовить все, что угодно: от exe до dll. На самом деле, «обыкновенных» объектных файлов в природе не бывает. Есть omf (в редакциях от Microsoft и IBM), coff, elf, aout и куча разной экзотики в стиле as86, rdf, ieee и т.д. Также заслуживает внимания возможность «сквозной» генерации двоичных файлов, не требующая помощи со стороны линкера. А некоторые ассемблеры (например, FASM) даже позволяют «вручную» генерировать исполняемые файлы и динамические библиотеки различных форматов, полностью контролируя процесс их создания и заполняя ключевые поля по своему усмотрению. Впрочем, программы, целиком написанные на ассемблере, — это либо вирусы, либо демки, либо учебные, либо обычный садомазохизм. На ассемблере чаще пишутся лишь системно-зависимые компоненты или модули, критичные к быстродействию, которые затем линкуются к основному проекту, и если ассемблер генерирует только omf, а компилятор — coff, то возникает проблема сборки «разнокалиберных» форматов воедино. Мне известен только один линкер, умеющий это делать, — ulink от Юрия Харона, он же обеспечивают нехилые возможности по сборке файлов «вручную», так что выбор конкретного ассемблерного транслятора целиком лежит на совести (и компетенции) программиста. Но все-таки лучше, чтобы и ассемблер, и компилятор генерировали одинаковые форматы объектных файлов.

Другой немаловажный критерий — количество поддерживаемых процессорных архитектур, которых в линейке x86 набралось уже больше десятка. Кстати, ни один из трансляторов не поддерживает набор команд x86-процессоров в полном объеме. Например, на MASM'е невозможно написать jmp 0007h:00000000h, и поэтому приходится прибегать к различным ухищрениям: либо реализовать команду через DB, что очень неудобно, либо заталкивать в стек сегмент/смещение, а потом делать retf, но это длинно, и к тому же воздействует на стек, которого у нас может и не быть.

MASM

Продукт жизнедеятельности ранней компании Microsoft, которой тот был нужен для создания MS-DOS, а позднее и для Windows 9x/NT. После выхода версии 6.13 продукт на некоторое время тормознул в развитии, но потом здравый смысл взял верх, и последняя версия (на момент написания этих строк — 6.13.8204) поддерживает уникод, все SSE/SSEII/SEEIII-расширения, объявляемые двумя директивами .686/.XMM, а также архитектуру AMD x86-64. Платформа Intel IA64 не поддерживается, но Microsoft поставляет Intel-ассемблер IAS.EXE.

Содержание  Вперед на стр. 092-118-2
ttfb: 2.936840057373 ms