1.1.1 Зачем еще один ассемблер?

Расширенный ассемблер вырос из идеи, поданной на comp.lang.asm.x86 (или возможно на alt.lang.asm - я забыл уже, где), когда по существу не было хорошего свободно доступного ассемблера серии x86 и нужно было, чтобы кто-то написал его.

a86 - хороший ассемблер, но не бесплатный, и если вы не заплатите, то 32-битный код писать не сможете - только DOS.
gas свободно доступен и портирован под DOS и Unix, но разработан для обратной совместимости с gcc. Поэтому проверка ошибок минимальна, к тому-же, с точки зрения любого, кто попробовал что-либо написать в нем - синтаксис ужасен. Плюс ко всему вы не можете в нем написать 16-разрядный код (по крайней мере, правильно).
as86 - только под Linux и (по крайней мере моя версия) кажется не имеет практически никакой документации.
MASM очень хорош, очень дорог и работает только под DOS.
TASM лучше, но все еще борется с MASM за совместимость, что означает миллионы директив и куча волокиты. Его синтаксис - по существу MASM-овский, но с противоречиями и причудами (в некоторой степени удаляемыми посредством режима Ideal). Он также дорогой и тоже - только ДОС.

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

1.1.2 Условия лицензирования

Чтобы ознакомиться с условиями лицензирования, при которых вы можете пользоваться NASM, пожалуйста, прочитайте файл Licence, являющийся неотъемлимой частью любого дистрибутивного архива NASM.

1.3.1 Инсталляция NASM под MS-DOS или Windows

При получении DOS-архива NASM, nasmXXX.zip (где XXX означает номер версии NASM, содержащегося в архиве), распакуйте его в отдельный каталог (например,c:\nasm).

Архив содержит четыре исполняемых файла: NASM-исполняемые файлы nasm.exe и nasmw.exe, и NDISASM-исполняемые файлы ndisasm.exe и ndisasmw.exe. Файлы, имеющие в окончании имени w, работают под Win9x/ME/NT, а те, которые без w - работают под DOS-ом.

Для запуска NASM требуются только эти файлы, так что скопируйте их в каталог, указанный в вашей переменной PATH , либо отредактируйте autoexec.bat для добавления пути к каталогу с исполнимыми файлами NASM в переменную PATH. (если вы устанавливаете только версию под Win32, можете смело переименовать nasmw.exe в nasm.exe.)

И это все!!! NASM установлен! Для запуска NASM не обязательно иметь отдельный каталог (если, конечно вы не добавили его к переменной PATH), поэтому можете удалить его (каталог), если у вас мало места на диске.

Если вы загрузили DOS-архив с исходниками nasmXXXs.zip, он будет также содержать полный исходный текст NASM и набор Make-файлов, которые вы можете (будем надеяться) использовать для перестроения вашей копии NASM "с нуля". В файле Readme перечислены все Make-файлы и указано, с какими компиляторами они работают.

Обратите внимание, что исходники insnsa.c, insnsd.c, insnsi.h и insnsn.c автоматически генерируются из главной таблицы инструкций insns.dat Perl-скриптом; файл macros.c генерируется из standard.mac другим Perl-скриптом. Хотя дистрибутив NASM 0.98 и включает эти автогенерируемые файлы, вам может потребоваться перестроить их (и следовательно, вам будет необходим интерпретатор Perl), если вы захотите изменить insns.dat, standard.mac или документацию. Возможно в будущем в исходниках не будет этих файлов вовсе. Версии Perl для ряда платформ, включая DOS и Windows, доступны на "http://www.cpan.org/ports/".

1.3.2 Инсталляция NASM под Unix

При получении Unix-архива исходников NASM, nasm-X.XX.tar.gz (где X.XX означает номер версии NASM в архиве) распакуйте его в каталог типа /usr/local/src. Архив при распаковке создаст собственный подкаталог nasm-X.XX.

NASM - автоконфигурируемый пакет: как только вы распакуете его, перейдите к каталогу, куда он был распакован и введитеe ./configure. Данный шелл-скрипт найдет самый подходящий компилятор C для сборки NASM и, соответственно, настройки Make-файлов.

Как только NASM сконфигурируется, вы можете ввести make для сборки бинарных файлов nasm и ndisasm, а затем ввести make install для установки их в /usr/local/bin и установки man-страниц nasm.1 и ndisasm.1 в /usr/local/man/man1. В качестве альтернативы вы можете указать опции типа --prefix к команде configure скрипта (подробности см. в файле INSTALL) или установить программы самостоятельно.

NASM также имеет набор утилит для обработки заказного формата объектных файлов RDOFF, находящихся в подкаталоге rdoff архива NASM. Вы можете собрать их при помощи make rdf и установить при помощи make rdf_install, если конечно они вам нужны.

Если NASM будет не в состоянии автоматически выбрать конфигурацию, вы все-же сможете скомпилировать его при помощи make-файла Makefile.unx. Cкопируйте или переименуйте этот файл в Makefile и попробуйте ввести make. Имеется также файл Makefile.unx в подкаталоге rdoff.

2.1.1 Ключ -o: Указание имени выходного файла

Обычно NASM выбирает имя выходного файла самостоятельно; так как это зависит от формата объектного файла. Если формат объектного файла - Microsoft (obj и win32), он удалит расширение .asm (или любое другое, какое вам нравится использовать - NASMу все равно) из имени исходного файла и заменит его на .obj. У объектных файлов Unix-формата (aout, coff, elf и as86) он будет заменять расширение на .o. Для формата rdf он будет использовать расширение .rdf, а в случае формата bin он просто удалит расширение, например из myfile.asm получится файл myfile.

Если выходной файл уже существует, NASM перезапишет его, если только его имя не совпадает с именем входного файла - в этом случае появится предупреждение и в качестве выходного файла будет использовано имя nasm.out.

В случаях, когда имя по умолчанию недопустимо, используйте ключ -o командной строки, позволяющий определить необходимое вам имя выходного файла. Имя выходного файла должно следовать за ключем -o, неважно с пробелом между ними или без. Например:

2.1.2 Ключ -f: Указание формата выходного файла

Если ключ -f в командной строке отсутствует, NASM будет выбирать формат выходного файла самостоятельно. В распространяемой версии NASM формат по умолчанию всегда bin; если вы создаете собственную копию NASM, то при компиляции можете переопределить значение OF_DEFAULT на то, которое вам нужно по умолчанию.

Как и для ключа -o, разделительный пробел между -f и форматом выходного файла необязателен: -f elf и -felf для NASM идентичны.

Полный список доступных выходных форматов может быть получен при помощи команды nasm -h.

2.1.3 Ключ -l: Генерация файла-листинга

Если в командной строке вы укажете ключ -l и имя файла (как обычно, пробел необязателен), NASM будет генерировать из исходника файл-листинг, где адреса и генерируемый код будут расположены слева, а исходный код с развернутыми многострочными макросами (за исключением тех, которые специально требуют обратное: см. ^{параграф 4.2.9}) - справа. Например:

2.1.4 Ключ -E: Перенаправление ошибок в файл

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

В связи с этим имеется специальный ключ -E, после которого указывается имя файла (пробел необязателен). Данный ключ перенаправляет стандартный поток ошибок в указанный файл. Таким образом, вы можете запустить NASM, например следующим образом:

2.1.5 Ключ -s: Перенаправление ошибок в stdout

Ключ -s перенаправляет стандартный поток ошибок stderr в выходной поток stdout (естественно, в MS-DOS). Например, для ассемблирования файла myfile.asm и передачи ошибок программе more, вы можете ввести следующее:

См. также ключ -E, ^{параграф 2.1.4}.

2.1.6 Ключ -i: Каталоги поиска включаемых файлов

Когда NASM встречает в исходнике директиву %include (см. ^{параграф 4.5}), он будет искать указанный в ней файл не только в текущем каталоге, но и во всех каталогах, указанных в командной строке при помощи ключа -i. Следовательно, вы можете включить файлы из, например, библиотеки макросов, введя следующую команду:

(Как обычно, пробел между -i и строкой поиска допустим, но не обязателен)

С целью переносимости кода в NASMе не "зашито" соглашение об именовании файлов той или иной ОС, под которой он запущен; строка, которую вы укажете как аргумент ключа, будет обработана в точности так, как есть. Заключительный обратный слэш в приведенном выше примере под Unix необходим, т.к. в этой ОС заключительные слэши обычно требуются.

(Вы можете извлечь из этого обстоятельства выгоду, использовав данный ключ "не по назначению" - например ключ -ifoo будет заставлять директиву %include "bar.i" искать файл foobar.i...)

Если вы хотите описать стандартный путь поиска включаемых файлов, такой как /usr/include в системе Unix, вы должны поместить одну или более директив -i в переменную окружения NASM (см. ^{параграф 2.1.13}).

Для совместимости с make-файлами большинства С компиляторов, данный ключ может быть также задан как -I.

2.1.7 Ключ -p: Предварительно включаемые файлы

При помощи ключа -p NASM позволяет вам предварительно включить некоторые файлы в ваш исходник. Так, строка запуска

эквивалентна строке nasm myfile.asm и помещением в начало файла директивы %include "myinc.inc". В целях симметричности с ключами I, -D и -U данный ключ может быть также задан как -P.

2.1.8 Ключ -d: Предопределение макроса

Аналогично тому, как ключ -p дает альтернативу помещения в начало исходного файла директивы %include, ключ -d дает альтернативу директиве %define. Таким образом, команда

альтернативна помещению в начало файла директивы

Вы можете также опустить значение константы: ключ -dFOO эквивалентен строке %define FOO. Данная возможность может быть полезна при ассемблировании для включения/выключения опций, проверяемых при помощи директивы %ifdef, например -dDEBUG. Для совместимости с make-файлами большинства С компиляторов, данный ключ может быть также задан как -D.

2.1.9 Ключ -u: Отмена определения макроса

Ключ -u отменяет определение ранее определенного макроса. Например, в результате выполнения следующей командной строки:

FOO не будет предопределенным макросом для программы. Это полезно для временного отключения опций, заданных в make-файлах. Для совместимости с make-файлами большинства С компиляторов, данный ключ может быть также задан как -U.

2.1.10 Ключ -e: Только препроцессирование

NASM допускает выполнение только препроцессирования входного файла. Использование ключа -e (не требующего параметров) заставит NASM препроцессировать входной файл, развернуть все макро ссылки, удалить все комментарии и директивы препроцессора и вывести результирующий файл в стандартный выходной поток (или сохранить его как отдельный файл, если используется также опция -о).

Данный ключ неприменим для программ, где препроцессор должен вычислить выражения, зависящие от значений адресов: такой код как

будет вызывать ошибку в режиме "только препроцессирование".

2.1.11 Ключ -a: Отключение препроцессора

Если NASM используется в качестве выходной части компилятора, то для увеличения скорости компиляции желательно полностью подавить препроцессирование в случае, если компилятор уже делает его. Ключ -a, не требующий никаких параметров, заставляет NASM заменить свой препроцессор ничего не делающей "заглушкой".

2.1.12 Ключ -w: Разрешение/Запрещение предупреждений при ассемблировании

В процессе ассемблирования NASM может замечать множество вещей, заслуживающих внимания пользователя, но не представляющих собой таких серьезных ошибок, чтобы NASM не смог сгенерировать выходной файл. Эти предупреждения выдаются так же, как и ошибки, но перед собственно сообщением добавляется слово "warning". Предупреждения не являются причиной прерывания процесса генерации выходного файла.

Некоторые события менее серьезны, чем другие: они только иногда заслуживают внимания пользователя. В связи с вышесказанным, NASM поддерживает ключ командной строки -w, включающий или выключающий определенные классы предупреждений. Эти классы предупреждений описываются по имени, например orphan-labels; вы можете разрешить предупреждения данного класса при помощи ключа -w+orphan-labels и запретить их ключом -w-orphan-labels.

Ниже перечислены классы подавляемых предупреждений:

macro-params включает предупреждения о многострочных макросах, которым передается неверное число параметров. Данный класс предупреждений по умолчанию разрешен; см. ^{параграф 4.2.1}, где приведен пример отключения этого класса.
orphan-labels включает предупреждения о строках исходника, не содержащих инструкций, но в которых описываются метки без завершающего двоеточия. NASM по умолчанию не предупреждает об этих вещах; см. пример в ^{параграфе 3.1}, где показано, как можно включить их.
number-overflow включает предупреждения о числовых константах, не вписывающихся в диапазон 32 бита (0x7fffffff). Данный класс предупреждений по умолчанию разрешен.

2.1.13 Переменная окружения NASM

Если вы определите переменную окружения NASM, программа будет интерпретировать ее как список дополнительных ключей командной строки, обрабатывающихся раньше "настоящих" параметров командной строки. Вы можете использовать эту возможность, например для описания стандартных каталогов поиска включаемых файлов, поместив в пременную NASM ключ -i.

Значение пременной разделяется пробелами, поэтому значение -s -ic:\nasmlib будет обработано как два отдельных ключа. В то же время значение -dNAME="my name" не будет воспринято так, как вы хотите (внутри есть пробел) и командный процессор NASMа соответственно не поймет двух бессмысленных параметров -dNAME="my и name".

Для разрешения этого введено следующее правило: если вы начинаете переменную NASM некоторым символом, не являющимся знаком "минус", NASM будет воспринимать этот символ как разделитель опций. Таким образом, значение

!-s!-ic:\nasmlib переменной NASM эквивалентно -s -ic:\nasmlib, но зато теперь !-dNAME="my name" будет работать правильно.

2.2.1 NASM чувствителен к регистру символов

Самым "простым" отличием является регистро-чувствительность NASM - он различает обращения к таким меткам, как foo, Foo или FOO. Если вы ассемблируете .obj-файлы для DOS или OS/2, то для перевода всех экспортируемых в другие модули символов в верхний регистр можете активизировать директиву UPPERCASE (описана в ^{параграфе 6.2}). Однако в пределах одного модуля NASM различает метки, отличающиеся друг от друга только регистром.

2.2.2 NASM требует квадратные скобки для ссылок на память

NASM был разработан, кроме всего прочего, для упрощения запоминания синтаксиса. Одна из целей проекта NASM состоит в том, чтобы везде, где это возможно, было взаимно однозначное соответствие между отдельной строкой кода NASM и генерируемой из нее инструкцией. В MASM вы этого сделать не можете: если определите, например,

затем напишете две строки кода

то будут сгенерированы две совершенно различных инструкции, несмотря на то, что синтаксис на вид совершенно идентичен.

NASM уходит от этой нежелательной ситуации путем упрощения синтаксиса для ссылок на память. Правило элементарно - любой доступ к содержимому памяти требует постановки квадратных скобок вокруг адреса, а при любом доступе к адресу переменной квадратные скобки не ставятся. Таким образом, инструкция вида mov ax,foo будет всегда ссылаться на константу времени компиляции, неважно EQU ли это или адрес переменной, в то же время для получения доступа к содержимому переменной bar вы должны использовать код mov ax,[bar].

Из этого также следует, что NASM не нуждается в ключевом слове MASMа OFFSET, т.к. MASMовский код mov ax,offset bar означает то же самое, что и mov ax,bar для NASM. Если вы накопили достаточно много кода, написанного под MASM и хотите использовать его в NASMе, вы всегда можете вставить строчку вида %idefine offset, указывающую препроцессору, что ключевое слово OFFSET является ничего не делающей инструкцией.

Данное несоответствие еще в большей степени присутствует в a86, где объявление метки с завершающим двоеточием описывает собственно метку, а без двоеточия - переменную. Так, в a86 инструкция mov ax,var будет вести себя по разному, в зависимости от объявления метки var: как var: dw 0 (это метка) или как var dw 0 (а это уже переменная размером в слово). NASM по сравнению с этим очень прост: все является метками.

NASM, в целях упрощения, не поддерживает гибридный синтаксис MASMа и его клонов, такой, как например mov ax,table[bx], где ссылка на память обозначена частью внутри квадратных скобок, а частью - вне их. Правильный синтаксис в NASM для указанной выше инструкции будет mov ax,[table+bx]. Соответственно, инструкция вида mov ax,es:[di] не поддерживается, правильная инструкция - mov ax,[es:di].

2.2.3 NASM не хранит типы переменных

NASM не запоминает определямые вами типы переменных. Поскольку MASM эти вещи запоминает, то при встрече var dw 0 он запомнит, что вы определили var как пременную размером в слово и затем будет способен разрешить неопределенность при появлении инструкции mov var,2. NASM же преднамеренно не будет помнить ничто относительно символа var за исключением того, где он начинается, поэтому вы должны явно указывать mov word [var],2.

В соответствии с этим, NASM не поддерживает инструкции LODS, MOVS, STOS, SCAS, CMPS, INS или OUTS, поддерживаются только их формы вида LODSB, MOVSW и SCASD, где явно задается размер компонентов обрабатываемой строки.

2.2.4 NASM не поддерживает ASSUME

Как часть общей идеологии упрощения, NASM не поддерживает директиву ASSUME. NASM не будет следить за тем, какие значения вы помещаете в сегментные регистры и поэтому никогда автоматически не будет генерировать префикс замены сегмента.

2.2.5 NASM не поддерживает модели памяти

NASM не имеет никаких директив для поддержки различных 16-битных моделей памяти. Программист должен самостоятельно следить, какие функции предполагается вызывать "дальним вызовом", а какие - ближним, и соответственно помещать правильную форму инструкции RET (RETN или RETF; NASM допускает применение RET в качестве альтернативной формы RETN); кроме того, программист ответственен за кодирование инструкций CALL FAR, где это необходимо при вызове внешних функций, и должен также следить, какие описания внешних переменных являются дальними, а какие - ближними.

2.2.6 Различия в обработке чисел с плавающей точкой

NASM, в отличие от MASM, использует другие имена для ссылок на регистры сопроцессора: MASM ссылается на эти регистры как ST(0), ST(1) и т.д., в NASMе для этой цели используются имена st0, st1 и т.д.

Начиная с версии 0.96, NASM обрабатывает инструкции форм "nowait" так же, как и MASM-совместимые ассемблеры. Особая обработка, использованная в версиях 0.95 и младше была основана на неправильном понимании авторами.

2.2.7 Прочие различия

По историческим причинам NASM использует ключевое слово TWORD там, где MASM и совместимые с ним ассемблеры используют TBYTE.

NASM объявляет резервируемое пространство (неиницализированные данные) не так, как MASM: там, где MASM-программист может написать stack db 64 dup (?), NASM требует следующее - stack resb 64, что интерпретируется как "резервирование 64 байт". Так как NASM обрабатывает ? как обычный символ, вы можете написать что-то вроде ? equ 0, а затем использовать dw ?, что будет возможно полезно для каких-то целей. DUP однако остается неподдерживаемым синтаксисом.

И, наконец, в дополнение ко всему вышесказанному, макросы и директивы NASM работают совершенно отлично от MASM. Подробности приведены в ^{главе 4} и ^{главе 5}.

3.2.1 DB и ее друзья: Объявление инициализированных данных

Как и в MASM, DB, DW, DD, DQ и DT используются для объявления инициализированных данных в выходном файле. Они могут использоваться достаточно многими способами:

DQ и DT не допускают в качестве операндов числовые или строковые константы.

3.2.2 RESB и ее друзья: Объявление неинициализированных данных

RESB, RESW, RESD, RESQ и REST разработаны для использования в BSS-секции модуля: они объявляют не инициализированное пространство для хранения данных. Каждая принимает один операнд, являющийся числом резервируемых байт, слов, двойных слов и т.д. Как было указано в ^{параграфе 2.2.7}, NASM не поддерживает синтаксис резервирования неинициализированного пространства, реализованный в MASM/TASM, где можно делать DW ? или подобные вещи: это заменено полностью. Операнд псевдо-инструкций класса RESB является критическим выражением: см. ^{параграф 3.7}.

Например:

3.2.3 INCBIN: Включение внешних бинарных файлов

INCBIN заимствована из старого ассемблера DevPac, работавшего на Amigе: она включает бинарный файл в выходной файл, оставляя его (бинарный файл) неизменным. Это может быть полезно (например) для включения картинок и музыки непосредственно исполняемый файл игрушки. Эта псевдо-инструкция может быть вызвана тремя разными способами:

3.2.4 EQU: Определение констант

EQU вводит символ для указанного константного значения: если используется EQU, в этой строке кода должна присутствовать метка. Смысл EQU - связать имя метки со значением ее (только) операнда. Данное определение абсолютно и не может быть позднее изменено. Например,

определяет msglen как константу 12. msglen не может быть позднее переопределено. Это не определение препроцессора: значение msglen обрабатывается здесь только один раз при помощи значения $ (что такое $ - см. ^{параграф 3.5}) в месте определения. Имейте в виду, что операнд EQU также является критическим выражением (^{параграф 3.7}).

3.2.5 TIMES: Повторение инструкций или данных

Префикс TIMES заставляет инструкцию ассемблироваться несколько раз. Данная псевдо-инструкция отчасти представляет NASM-эквивалент синтаксиса DUP, поддерживающегося MASM-совместимыми ассемблерами. Вы можете написать, например

или что-то подобное; однако TIMES более разносторонняя инструкция. Аргумент TIMES - не просто числовая константа, а числовое выражение, поэтому вы можете писать следующие вещи:

При этом будет резервироваться строго определенное пространство, начиная от метки buffer и длиной 64 байта. Наконец, TIMES может использоваться в обычных инструкциях, так что вы можете писать тривиальные развернутые циклы:

Заметим, что нет никакой принципиальной разницы между times 100 resb 1 и resb 100 за исключением того, что последняя инструкция будет обрабатываться примерно в 100 раз быстрее из-за внутренней структуры ассемблера.

Операнд псевдо-инструкции TIMES, подобно EQU и RESB, является критическим выражением (^{параграф 3.7}).

Имейте также в виду, что TIMES не применима в макросах: причиной служит то, что TIMES обрабатывается после макро-фазы, позволяющей аргументу TIMES содержать выражение, подобное 64-$+buffer. Для повторения более одной строки кода или в сложных макросах используйте директиву препроцессора %rep.

3.4.1 Числовые константы

Числовая константа - это просто число. NASM позволят определять числа в различных системах счисления и различными способами: вы можете использовать суффиксы H, Q и B для шестнадцатеричных, восьмеричных и двоичных чисел соответственно; можете использовать для шестнадцатеричных чисел префикс 0х в стиле С, а также префикс $ в стиле Borland Pascal. Однако имейте в виду, что префикс $ может быть также префиксом идентификаторов (см. ^{параграф 3.1}), поэтому первой цифрой шестнадцатеричного числа при использовании этого префикса должна быть обязательно цифра, а не буква.

Некоторые примеры числовых констант:

3.4.2 Символьные константы

Символьная константа содержит от одного до четырех символов, заключенных в одиночные или двойные кавычки. Тип кавычек для NASM несущественен, поэтому если используются одинарные кавычки, двойные могут выступать в роли символа и, соответственно, наоборот.

Символьная константа, содержащая более одного символа, будет загружаться в обратном порядке следования байт: если вы пишете

сгенерированной константой будет не 0x61626364, а 0x64636261, поэтому если сохранить эту константу в память, а затем прочитать, получится снова abcd, но никак не dcba. Это также влияет на инструкцию CPUID Пентиумов (см. ^{section A.29}).

3.4.3 Строковые константы

Строковые константы допустимы только в некоторых псевдо-инструкциях, а именно в семействе DB и инструкции INCBIN. Строковые константы похожи на символьные, только длиннее. Они обрабатываются как сцепленные друг с другом символьные константы. Так, например, следующие строки кода эквивалентны.

Следующие строки также эквивалентны:

Обратите внимание, что когда используется db, константа типа 'ab' обрабатывается как строковая, хотя и достаточно коротка, чтобы быть символьной, потому что иначе db 'ab' имело бы тот же смысл, какой и db 'a', что глупо. Соответственно, трех- или четырехсимвольные константы, являющиеся операндами инструкции dw, обрабатываются также как строки.

3.4.4 Константы с плавающей точкой

Константы с плавающей точкой допустимы только в качестве аргументов DD, DQ и DT. Выражаются они традиционно: цифры, затем точка, затем возможно цифры после точки, и наконец, необязательная Е с последующей степенью. Точка обязательна, т.к. dd 1 NASM воспримет как объявление целой константы, в то время как dd 1.0 будет воспринята им правильно.

Несколько примеров:

В процессе компиляции NASM не может проводить вычисления над константами с плавающей точкой (это сделано с целью переносимости). Несмотря на то, что NASM генерирует код для х86 процессоров, сам по себе ассемблер может работать на любой системе с ANCI C компилятором. Само собой, ассемблер не может гарантировать присутствия устройства, обрабатывающего числа с плавающей точкой в формате Intel, поэтому стало бы необходимо включить собственный полный набор подпрограмм для работы с такими числами, что неизбежно привело бы к значительному увеличению размера самого ассемблера, хотя польза от этого была бы минимальна.

3.5.1 |: Побитовый оператор ИЛИ

Оператор | производит побитовую операцию ИЛИ, соответствующую процессорной инструкции OR. Побитовое ИЛИ имеет самый низкий приоритет среди арифметических операторов, поддерживаемых NASMом.

3.5.2 ^: Побитовый оператор ИСКЛЮЧАЮЩЕЕ ИЛИ

Оператор ^ обеспечивает выполнение побитовой операции ИСКЛЮЧАЮЩЕЕ ИЛИ.

3.5.3 &: Побитовый оператор И

Оператор & обеспечивает выполнение побитовой операции И.

3.5.4 << и >>: Операторы сдвига бит

<< производит сдвиг бит влево точно так, как это делается в С. Так, 5<<3 обрабатывается как 5 умножить на 8, или 40. >> производит сдвиг бит вправо; в NASM этот сдвиг всегда беззнаковый, поэтому биты, освобождаемые слева в результате сдвига, заполняются нулями, а не старшим знаковым разрядом.

3.5.5 + и -: Операторы сложения и вычитания

Операторы + и - выполняют обычное сложение и вычитание.

3.5.6 *, /, //, % и %%: Умножение и деление

* является оператором умножения. Операторы / и // обозначают деление: / соответствует беззнаковому делению, а // - знаковому. Подобно этому, операторы % и %% обеспечивают соответственно беззнаковое и знаковое получение остатка от деления (взятие по модулю).

NASM, также как и ANSI C, не дает никаких гарантий о физическом смысле знакового оператора взятия по модулю.

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

3.5.7 Унарные операторы: +, -, ~ и SEG

Наивысший приоритет в грамматике выражений NASM имеют операторы, применяемые к одному аргументу: оператор "минус" (-) изменяет знак своего операнда, оператор "плюс" (+) ничего не делает (введен для симметричности с минусом), оператор "тильда" (~) вычисляет дополнение операнда, а оператор SEG извлекает сегментный адрес операнда (более подробно описывается в ^{параграфе 3.6}).

4.1.1 Обычный способ: %define

Однострочные макросы описываются при помощи директивы препроцессора %define. Определения работают подобно языку С; т.е. вы можете сделать что-то наподобие

что будет развернуто в

Если однострочный макрос содержит символы, вызывающие другой макрос, то развертывание первого осуществляется в процессе вызова, а не при определении. Так, код

будет обработан как и ожидается - mov ax,1+2*8, несмотря на то, что при описании a макрос b еще не определен.

Макросы, описываемые конструкцией %define, регистрочувствительны: после %define foo bar только foo будет развернуто в bar, но никак не Foo или FOO. При использовании вместо %define конструкции %idefine ('i' от слова 'insensitive') вы можете сразу описать все варианты комбинации строчных и прописных букв в имени макроса, поэтому %idefine foo bar будет развертывать в bar не только foo, но и Foo, FOO, fOO и т.п.

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

макрос a(3) будет развернут единожды, т.е. в конструкцию 1+a(3) и дальнейшее развертывание производиться не будет. Данная возможность может быть полезна: в ^{параграфе 8.1} имеется соответствующий пример.

Вы можете перегружать однострочные макросы: если вы напишете

препроцессор, подсчитав передаваемые вами параметры, корректно обработает оба типа вызова макроса: foo(3) будет развернуто в 1+3, в то время как foo(ebx,2) - в 1+ebx*2. В то же время, если вы напишете

последующие описания foo будут запрещены: макрос без параметров не допускает описание макроса с тем же именем, но с параметрами, и наоборот.

Несмотря на это, переопределение однострочных макросов не запрещается: вы можете легко описать макрос как

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

Когда макрос foo будет вызван, он развернется в соответствии с самым поздним своим описанием. Это полезно в основном при описании однострочных макросов с конструкцией %assign (см. ^{параграф 4.1.4}).

Вы можете переопределить однострочный макрос при помощи ключа '-d' командной строки NASM: см. ^{параграф 2.1.8}.

При описании однострочных макросов вы можете объединять строки при помощи псевдо-оператора %+. Например:

После первого развертывания третья строка примет вид "_myfunc". При дальнейшей обработке препроцессор развернет эту строку в "_otherunc".

4.1.2 Однострочные макросы раннего связыванияs: %xdefine

Механизм %define, описанный в предыдущем параграфе, обеспечивает описание однострочных макросов с поздним связыванием, при котором ссылки на другие макросы разворачиваются при их вызове, поэтому если вы в это время измените внутренний макрос, значение развернутого макроса соответственно изменится. Это свойство полезно, но в некоторых случаях нежелательно. Например:

Если в этом примере вместо %xdefine мы используем %define, оба макроса будут развернуты в одно и то же значение dword [esp+8], что неверно. При использовании конструкции %xdefine макрос разворачивается во время его определения, поэтому a будет развернуто в dword [esp+0], а b - в dword [esp+4].

Макрос %xdefine имеет нечувствительный к регистру эквивалент %ixdefine, работающий так же, как и %idefine по отношению к %define.

4.1.3 Отмена определения макроса: %undef

Команда %undef удаляет однострочные макросы. Например, следующая последовательность:

будет развернута в инструкцию mov eax, foo, так как после %undef макрос foo больше не определен.

Отмена определения предопределенных макросов может быть осуществлена при помощи ключа '-u' командной строки NASM: см. ^{параграф 2.1.9}.

4.1.4 Переменные препроцессора: %assign

Альтернативным способом определения однострочных макросов является использование директивы %assign (и ее нечувствительного к регистру эквивалента %iassign, отличающегося от %assign тем же самым, чем %idefine отличается от %define).

Данная директива используется для определения однострочного макроса без параметров, но включающего числовое значение. Это значение может быть задано в форме выражения и обрабатывается оно только один раз - при обработке директивы %assign.

Как и в случае %define, макрос, определенный при помощи %assign, может быть позднее переопределен, например следующая строка

увеличивает числовое значение макроса.

%assign полезна для контроля завершения препроцессорных циклов %rep: пример этого см. в ^{параграфе 4.4}. Другие примеры применения %assign можно найти в ^{параграфе 7.4} и ^{парарафе 8.1}.

Выражение, передаваемое %assign, является критическим (см. ^{параграф 3.7}) и должно на выходе давать просто число (не включая в себя различные перемещающиеся ссылки наподобие адресов кода и данных).

4.2.1 Перегрузка многострочных макросов

Многострочные макросы, как и однострочные, могут быть перегружены путем определения одного и того же имени несколько раз с разным числом параметров. В отличие от однострочных макросов, здесь не делается исключений даже для макросов без параметров. Так, вы можете написать

для определения альтернативной формы функции-пролога, не выделяющей место в стеке.

Иногда вам может захотеться "перегрузить" процессорные инструкции; например, если вы определите

позже вы сможете написать

По умолчанию NASM будет выдавать предупреждение при обработке первой из этих строк, так как push теперь определена как макрос и вызывается с числом параметров, определения для которого нет. При этом будет сгенерирован корректный код, однако ассемблер даст предупреждение. Данное предупреждение можно отключить при помощи ключа командной строки -w-macro-params (см. ^{параграф 2.1.12}).

4.2.2 Локальные метки в макросах

NASM позволяет внутри определения многострочного макроса описать метки, которые останутся локальными для каждого вызова макроса: при многократном вызове макроса имена меток каждый раз будут изменяться. Описание такой метки осуществляется при помощи префикса %%. Например, вы можете описать инструкцию, выполняющую RET если флаг Z установлен, следующим образом:

После этого вы можете вызывать этот макрос столько раз, сколько нужно, и при этом в каждом вызове вместо метки %%skip NASM будет подставлять разные "реальные" имена. NASM создает имена в форме [email protected], где число 2345 изменяется при каждом вызове макроса. Префикс ..@ предотвращает пересечение имен локальных меток макросов с механизмом обычных локальных меток, описанным в ^{параграфе 3.8}. В связи с этим вам нужно избегать определения собственных меток в такой форме (префикс ..@, затем число, затем точка), иначе они могут совпасть с локальными метками макросов.

4.2.3 Поглощающие параметры макросов

Иногда полезно определить макрос, собирающий всю командную строку в один параметр после извлечения одного или двух небольших параметров из начала очереди. Примером здесь может служить макрос, записывающий строку в файл MS-DOS, где вы можете захотеть написать что-то вроде

NASM позволяет определить последний параметр макроса в качестве поглощающего. Это означает, что если вы вызовете макрос с большим числом параметров, чем ожидалось, все "лишние" параметры вместе с разделительными запятыми присоединятся к последнему ожидаемому параметру. Так, если вы напишете:

то приведенный выше пример вызова макроса writefile будет работать как нужно: текст перед первой запятой [filehandle] используется в качестве первого параметра и развернется, когда встретится ссылка %1, весь последующий текст объединится в %2 и расположится после db.

Поглощающая природа макроса указывается в NASM при помощи знака (+) после количества параметров в строке %macro.

При определении поглощающего макроса вы тем самым говорите NASM, как он должен разворачивать любое число параметров свыше явно указанного; в приведенном случае, например, он будет знать, что должен делать при вызове writefile с 2,3,4 или большим числом параметров. NASM также будет это учитывать при перегрузке макросов и не позволит вам определить другую форму writefile, принимающую к примеру 4 параметра.

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

NASM поддерживает оба механизма помещения запятых в параметры макроса и вам самим выбирать, какой предпочтительнее в каждом конкретном случае.

В ^{параграфе 5.2.1} приведен более "продвинутый" способ написания рассмотренного макроса

4.2.4 Параметры макросов по умолчанию

NASM позволяет также определять многострочный макрос с указанием диапазона допустимого количества параметров. Если вы используете эту возможность, то можете задать значения по умолчанию для пропускаемых параметров. Например:

Данный макрос (использующий макрос writefile, описанный в ^{параграфе 4.2.3}) может быть вызван как с явно указанным сообщением об ошибке, помещаемым в выходной поток перед закрытием, так и без параметров. В последнем случае в качестве параметра будет подставлено сообщение по умолчанию, введенное при определении макроса.

Обычно для макроса данного типа вы задаете минимальное и максимальное число параметров; минимальное число - это параметры, требующиеся при вызове макроса, а для остальных вы задаете значения по умолчанию. Так, если определение макроса начинается со строки

то он может быть вызван с числом параметров от одного до трех; при этом параметр %1 всегда берется из строки вызова макроса, параметр %2 (если не задан) примет значение eax, а параметр %3 (если не задан) - значение [ebx+2].

Вы не обязаны задавать значения по умолчанию при определении макроса - в этом случае они будут пустые. Это может быть полезно для макросов, принимающих различное число параметров, так как число реально передаваемых параметров вы можете указать при помощи конструкции %0 (см. ^{параграф 4.2.5} ниже).

Механизм параметров по умолчанию может комбинироваться с механизмом поглощающих параметров; например, описанный выше макрос die может быть сделан более продвинутым и полезным путем изменения первой строки определения:

Максимальное число параметров может быть неограниченным, что обозначается как *. В этом случае, конечно невозможно предусмотреть полный набор параметров по умолчанию. Примеры такого типа макросов см. в ^{параграфе 4.2.6}.

4.2.5 %0: Счетчик макро-параметров

Параметр %0 возвращает числовую константу, представляющую собой количество передаваемых в макрос параметров. Он может использоваться как аргумент для %rep (см. ^{параграф 4.4}) с целью перебора всех параметров макроса. Примеры см. в ^{параграфе 4.2.6} ниже.

4.2.6 %rotate: "Вращение" параметров макросов

Unix-программисты знакомы с командой shift оболочки, позволяющей "сдвигать" переданные шелл-скриптом аргументы ($1, $2 и т.д.) так, что аргумент, имевший до этого ссылку $2, получает ссылку $1, а имевший ссылку $1, становится недоступен.

NASM обеспечивает подобный механизм при помощи %rotate. Как видно по имени, эта команда отличается от команды Unix тем, что параметры не теряются: "выталкиваемые" с левого конца списка аргументов, они появляются на правом, и наоборот.

%rotate вызывается с одним числовым аргументом (который может быть выражением). Параметры макроса "вращаются" влево на количество мест, указанных аргументом. Если аргумент отрицателен, параметры вращаются вправо.

Например, пара макросов для сохранения и восстановления набора регистров может работать так:

Этот макрос вызывает инструкцию PUSH для каждого аргумента, слева-направо. Начинается это дело с сохранения первого аргумента, %1, затем вызывается %rotate для перемещения всех аргументов на один шаг влево, так что изначально второй аргумент становится доступен как %1. Повторение данной процедуры для всего набора аргументов (достигается это передачей %0 как аргумента для %rep) позволяет сохранить каждый из них.

Обратите внимание на использование звездочки (*) в качестве максимального числа параметров. Это означает, что число передаваемых макросу multipush параметров не ограничено.

Удобно иметь под рукой и обратный макрос, извлекающий регистры из стека, особенно если он не требует передавать ему аргументы в обратном порядке относительно PUSH. В идеале вы будете помещать в текст программы вызов макроса multipush, затем копировать эту строку, вставлять ее туда, где требуется извлечение из стека и заменять имя вызываемого макроса на multipop. И этот макрос будет извлекать регистры со стека в порядке, обратном тому, в каком их туда поместили.

Все это может быть реализовано при помощи следующего определения:

Данный макрос начинает работу с поворота своих аргументов вправо, поэтому исходный последний аргумент становится аргументом %1. Затем этот аргумент извлекается из стека, список аргументов снова поворачивается вправо и теперь аргументом %1 становится аргумент, бывший в начале предпоследним. Таким образом, аргументы извлекаются из стека в обратном порядке.

4.2.7 Объединение параметров макросов

NASM может объединять параметры макросов с окружающим их текстом. Это позволяет при определении макроса объявлять, например семейства символов. Если вы, например, захотите создать таблицу кодов клавиш вместе со смещениями в этой таблице, вы можете написать:

Это будет развернуто следующим образом:

Точно также можно присоединять текст к другому концу параметра, написав %1foo.

Если вам требуется присоединить к параметру макроса цифру, например для определения меток foo1 и foo2 при передаче параметра foo, вы не можете написать %11, так как это будет воспринято как одиннадцатый параметр макроса. Вместо этого вы должны написать %{1}1, где первая единица (определяющая номер параметра макроса) будет отделена от второй (представляющей собой присоединяемый к параметру текст).

Объединение может быть применено и к другим встраиваемым объектам препроцессора, таким как локальные метки макросов (^{параграф 4.2.2}) и контекстно-локальные метки (^{параграф 4.6.2}). В любом случае, неопределенность синтаксиса может быть разрешена путем заключения всего, находящегося после знака % и перед присоединяемым текстом, в фигурные скобки: %{%foo}bar прицепит текст bar к действительному имени локальной метки %%foo. (Это вообще-то излишне, так как форма, используемая NASM для генерации реальных имен локальных макро-меток подразумевает, что и %{%foo}bar, и %%foobar будут развернуты в одно и то же, однако возможность существует).

4.2.8 Коды условий в качестве параметров макросов

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

Однако более полезной возможностью является ссылка на макро-параметр вида %-1, которую NASM будет разворачивать как обратный код условия. Так, макрос retz, описанный в ^{параграфе 4.2.2}, может быть заменен макросом условного возврата более общего вида:

Данный макрос может быть теперь вызван как retc ne, что будет развернуто в инструкцию условного перехода JE, или как retc po, что будет преобразовано в переход JPE.

Ссылка %+1 на макро-параметр может вполне спокойно интерпретировать аргументы CXZ и ECXZ как правильные коды условий; однако если передать эту лабуду ссылке %-1, будет сообщено об ошибке, так как обратных кодов условий к таким параметрам не существует.

4.2.9 Подавление развертывания макросов в листинге

Когда NASM генерирует из программы файл листинга, он обычно разворачивает многострочные макросы посредством записи макро-вызова и последующим перечислением каждой строки, полученной в результате развертывания. Это позволяет увидеть, как генерируются инструкции из макроса в реальный код; однако для некоторых макросов данное загромождение листинга не требуется.

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

Или так:

4.3.1 %ifdef: Проверка присутствия однострочного макроса

Начинающийся со строки %ifdef MACRO условно-ассемблируемый блок будет обрабатываться только в том случае, если определен однострочный макрос MACRO. Если он не определен, вместо этого будут обрабатываться блоки %elif и %else (если они есть).

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

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

Для осуществления обратной проверки (отсутствия определения макроса) вы можете использовать вместо %ifdef оператор %ifndef. Вы можете также тестировать наличие определения макроса в блоках %elif при помощи операторов %elifdef и %elifndef.

4.3.2 %ifctx: Проверка контекстного стека

Конструкция условного ассемблирования %ifctx ctxname предполагает обработку идущего вслед за ней кода только тогда, когда на вершине контекстного стека препроцессора находится имя ctxname. Как и в случае с %ifdef, поддерживаются также формы %ifnctx,%elifctx и %elifnctx.

Более подробно о контекстном стеке можно узнать в ^{параграфе 4.6}. а пример использования %ifctx приведен в ^{параграфе 4.6.5}.

4.3.3 %if: Проверка произвольных числовых выражений

Конструкция условного ассемблирования %if expr будет вызывать обработку последующего кода только в том случае, если выражение expr не нулевое. Примером использования данной конструкции может служить проверка выхода из препроцессорного цикла %rep: пример смотрите в ^{параграфе 4.4}.

Выражения, указываемые для %if, а также его эквивалента %elif, являются критическими (см. ^{параграф 3.7}).

%if расширяет обычный синтаксис выражений NASM, предусматривая набор операторов отношения, которые в выражениях обычно запрещены. Операторы =, <, >, <=, >= и проверяют на равенство, отношения "меньше чем", "больше чем", "меньше или равно", "больше или равно" и на неравенство соответственно. С-подобные формы == и != также поддерживаются и являются альтернативными формами = и . И наконец, имеются операторы низкого приоритета &&, ^^ и ||, производящие логические операции И, ИСКЛЮЧАЮЩЕЕ ИЛИ и ИЛИ. Они работают также, как логические операторы в С (за исключением того, что в С нет логического "ИСКЛЮЧАЮЩЕЕ ИЛИ"), то есть возвращают всегда 0 или 1 и обрабатывают любое ненулевое значение как 1 (например, ^^ возвращает 1 только если одно из его входных значений нулевое, а второе - ненулевое). Операторы отношения также возвращают 1 если условие истинно и 0 - если ложно.

4.3.4 %ifidn и %ifidni: Проверка на идентичность текста

Конструкция %ifidn text1,text2 будет вызывать ассемблирование последующего кода только в том случае, если текст аргументов text1 и text2 после развертывания однострочных макросов становится идентичным. Отличия в виде пробелов не считаются.

%ifidni подобна %ifidn, но нечувствительна к регистру символов.

Например, следующий макрос помещает регистр или число в стек, позволяя при этом обрабатывать IP как реальный регистр:

Как и большинство других %if-конструкций, %ifidn имеет эквивалент %elifidn и обратные формы %ifnidn и %elifnidn. Соответственно, %ifidni имеет эквивалент %elifidni и обратные формы %ifnidni и %elifnidni.

4.3.5 %ifid, %ifnum, %ifstr: Проверка типов символов

Иногда вам может понадобиться, чтобы макросы выполняли различные задачи в зависимости от того, что им передано в качестве аргумента: число, строка или идентификатор. Например, может быть необходимо чтобы макрос смог обрабатывать как строковые константы, так и указатели на уже существующие строки.

Конструкция условного ассемблирования %ifid, принимающая один параметр (который может быть пустым), обрабатывает последующий код только в том случае, если первый символ в параметре существует и является идентификатором. %ifnum работает аналогично, но проверяет символ на соответствие числовой константе; %ifstr тестирует на соответствие символа строке.

Например, описанный в ^{параграфе 4.2.3} макрос writefile может быть расширен для использования преимуществ конструкции %ifstr следующим образом:

После этого макрос writefile может "справиться" со следующими двумя своими вызовами:

В первом случае strpointer используется в качестве адреса уже объявленной строки, а length - как длина этой строки. Во втором случае макросу передается строка, которую макрос объявляет и получает ее адрес и длину самостоятельно.

Обратите внимание на использование %if внутри %ifstr: это нужно для определения того, передано ли макросу 2 аргумента (в этом случае строка - просто константа и ей достаточно db %2) или больше (в этом случае все аргументы кроме первых двух объединяются в %3 и тогда уже требуется db %2,%3).

Для всех трех конструкций %ifid, %ifnum и %ifstr существуют соответствующие версии %elifXXX, %ifnXXX и %elifnXXX.

4.3.6 %error: Сообщения об ошибках, определяемых пользователем

Директива препроцессора %error заставляет NASM сообщать об ошибках, случающихся на стадии ассемблирования. Так, если ваши исходники будет ассемблировать кто-то еще, вы можете проверить, определен ли нужный макрос при помощи следующего кода:

Таким образом любой пользователь, не знающий, как правильно ассемблировать ваш код, будет быстро предупрежден об этом несоответствии, вместо того, чтобы увидеть крах программы при ее выполнении и не знать, что этот крах вызвало.

4.6.1 %push и %pop: Создание и удаление контекста

Директива %push используется для создания нового контекста и помещения его на вершину контекстного стека. Эта директива требует указания одного аргумента, а именно имени контекста. Например:

Эта команда помещает в стек новый контекст foobar. Вы можете иметь в стеке несколько контекстов с одним и тем же именем: они все равно будут отличаться друг от друга.

Директива %pop, не требующая аргументов, удалает самый верхний контекст из стека и разрушает его вместе с любыми связанными с ним метками.

4.6.2 Контектно-локальные метки

Точно так же, как использование %%foo вводит локальную по отношению к определенному макросу метку, конструкция %$foo используется для определения метки, локальной по отношению к контексту на вершине контекстного стека. Таким образом, пример с циклом REPEAT - UNTIL может быть реализован следующим образом:

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

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

Если вам требуется определить или получить доступ к меткам, локальным к контексту, находящемуся ниже вершины стека, вы можете использовать %$$foo, или %$$$foo для еще более "глубокого" контекста и т.д.

4.6.3 Контекстно-локальные однострочные макросы

NASM позволяет определять однострочные макросы, локальные по отношению к определенному контексту. Например,

будет определять однострочный макрос %$localmac, локальный к контексту на вершине стека. Само собой, после создания еще одного контекста директивой %push, данный макрос может быть доступен по имени %$$localmac.

4.6.4 %repl: Переименование контекста

Если вам требуется изменить имя контекста, находящегося на вершине стека , вы можете выполнить %pop с последующим %push; однако это будет иметь "побочный" эффект в виде разрушения всех локальных по отношению к извлеваемому контексту меток и макросов.

В NASM для этой цели предусмотрена директива %repl, изменяющая имя контекста без затрагивания связанных с этим контекстом локальных меток и макросов. Теперь вы можете заменить деструктивный код

на недеструктивную версию %repl newname.

4.6.5 Пример использования контекстного стека: Блок IF

В данном примере для реализации блока IF как набора макросов использованы почти все возможности контекстного стека, включая конструкцию условного ассемблирования %ifctx.

Данный код более устойчив, чем макросы REPEAT и UNTIL из ^{параграфа 4.6.2}, так как он использует условное ассемблирование для проверки правильного порядка следования макросов (например, нельзя перед if вызвать endif) и привлекает директиву %error, если порядок нарушен.

Кроме того, макрос endif способен справиться сразу с двумя разными условиями: следует ли он сразу за if или за else. Достигается это опять же за счет условного ассемблирования, при котором производятся разные действия в зависимости от того, что на вершине стека - if или else.

Макрос else должен сохранить контекст в стеке, чтобы метка %$ifnot, на которую ссылается if была той же самой, что и определенная в макросе endif, но в то же время он должен изменить имя контекста, чтобы endif знал, что тут поработал else. Он делает это при помощи %repl.

Пример использования макроса выглядит следующим образом:

Макросы блока IF совершенно спокойно обрабатывают вложенность посредством сохранения контекста, вводимого внутри if поверх контекста, описанного извне if; таким образом else и endif всегда ссылаются на последние if или else, не имеющие на этот момент пары.

4.7.1 __NASM_MAJOR__ и __NASM_MINOR__: Версия NASM

Однострочные макросы __NASM_MAJOR__ и __NASM_MINOR__ разворачиваются соответственно в старшую и младшую части номера версии NASM. Так, в NASM 0.96 __NASM_MAJOR__ будет определен как 0, а __NASM_MINOR__ - как 96.

4.7.2 __FILE__ и __LINE__: Имя файла и номер строки

Как и в препроцессоре С, NASM позволяет пользователю узнать имя файла и номер строки, содержащие текущую инструкцию. Макрос __FILE__ разворачивается в строковую константу, представляющую собой имя текущего входного файла (которое в ходе ассемблирования может изменяться, если используется директива %include), а __LINE__ разворачивается в числовую константу, означающую текущий номер строки во входном файле.

Эти макросы могут быть использованы, например, для передачи макросу отладочной информации, так как вызов __LINE__ внутри макроопределения (неважно, одно- или многострочного) будет возвращать номер строки макровызова, а не строки определения. Так, например, для определения в какой части кода наступает крах, пишется подпрограммка stillhere, которой передается в EAX номер строки, а на выходе получается что-то вроде "строка 155: я еще жива". Затем вы пишете макрос

и "утыкаете" ваш код вызовами notdeadyet до тех пор, пока не найдете точку краха.

4.7.3 STRUC и ENDSTRUC: Объявление структурных типов данных

Ядро NASM не содержит внутренних механизмов для определения структур данных; вместо этого сделан довольно мощный препроцессор, который кроме всего прочего способен реализовать структуры данных в виде набора макросов. Для определения структур данных используются макросы STRUC и ENDSTRUC.

STRUC принимает один параметр, являющийся именем типа данных. Данное имя описывается как символ со значением 0, затем к нему присоединяется суффикс _size и оно определяется как EQU с размером структуры. После того, как STRUC выполнена, вы описываете структуру данных путем определения полей при помощи семейства псевдо-инструкций RESB. В конце описания вы должны вызвать ENDSTRUC.

Например, для определения структуры mytype, содержащей двойное слово, слово, байт и строку, вы можете написать:

Данный код определяет шесть символов: mt_long как 0 (смещение от начала структуры mytype до поля с двойным словом), mt_word как 4, mt_byte как 6, mt_str как 7, mytype_size как 39 и собственно mytype как ноль.

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

Здесь описываются смещения к полям структуры в виде mytype.long, mytype.word, mytype.byte и mytype.str.

Так как NASM не имеет встроенной поддержки структур, он не поддерживает формы нотации как в языке С с использованием точки для ссылки на элементы структуры (за исключением нотации локальных меток), поэтому код наподобие mov ax,[mystruc.mt_word] будет ошибочным. Константа mt_word подобна любым другим константам, поэтому корректным синтаксисом в этом случае будет mov ax,[mystruc+mt_word] или mov ax,[mystruc+mytype.word].

4.7.4 ISTRUC, AT иIEND: Объявление экземпляров структур

Имея определение структуры, вы вслед за этим обычно захотите объявить экземпляры этой структуры в сегменте данных (иначе зачем она вообще нужна). NASM предусматривает для этого простой способ с использованием механизма ISTRUC. Для объявления в программе структуры типа mytype вы должны написать следующий код:

Функцией макроса AT является продвижение позиции ассемблирования (при помощи префикса TIMES) в корректную точку заданного поля структуры и затем объявления указанных данных. Вследствие этого, поля структуры должны объявляться в том же самом порядке, в каком они следовали при определении.

Если данные, передаваемые в поле структуры, не помещаются на одной строке, оставшаяся их часть может просто следовать за строкой с AT. Например:

В зависимости от личных предпочтений, вы можете также полностью пропустить код на строке AT и начать поле структуры со следующей строки:

4.7.5 ALIGN и ALIGNB: Выравнивание данных

Макросы ALIGN и ALIGNB предоставляют удобный способ выравнивания кода или данных по словам, двойным словам, параграфам (16 байт) или другим границам. (В некоторых ассемблерах для этой цели служит директива EVEN). Синтаксис ALIGN и ALIGNB следующий:

Оба макроса требуют, чтобы их первый аргумент был степенью двойки; они подсчитывают число дополнительных байт, требуемых для подгонки длины текущей секции до соответствующей границы (произведение со степенью двойки) и затем осуществляют выравнивание путем применения к своему второму аргументу префикса TIMES.

Если второй аргумент не задан, используется значение по умолчанию: NOP для ALIGN и RESB 1 для ALIGNB. Если второй аргумент задан, оба макроса становятся эквивалентными. Обычно вы должны использовать ALIGN в секциях кода и данных, а ALIGNB - в секции BSS. Тогда никакого второго аргумента не понадобится (кроме, конечно, специальных случаев).

Так как ALIGN и ALIGNB являются простыми макросами, проверки ошибок в них нет: они не могут сообщить вам о том, что переданный аргумент не является степенью двойки или что второй аргумент генерирует более одного байта кода. В любом таком случае они будут "молча делать плохие вещи".

ALIGNB (или ALIGN со вторым аргументом RESB 1) могут использоваться при определении структур:

Таким образом гарантируется, что члены структуры осмысленно выровнены относительно ее базы.

И последнее замечание: ALIGN и ALIGNB работают относительно начала секции, а не начала адресного пространства в конечном исполнимом файле. Например, выравнивание по параграфам в секциях, гарантирующих свое выравнивание только по двойным словам - пустая трата времени. NASM не в состоянии проверить, что характеристики выравнивания секции подходят для использования ALIGN или ALIGNB.

5.2.1 Макрос __SECT__

Директива SECTION необычна тем, что ее пользовательская форма функционально отличается от примитивной. Примитивная форма [SECTION xyz] просто переключает текущую секцию на указанную. Пользовательская форма SECTION xyz сначала определяет однострочный макрос __SECT__ для примитивной директивы [SECTION], которую собирается выдать, и затем выдает ее. Таким образом, пользовательская директива

развернется в две строки:

Пользователи могут использовать это в своих собственных макросах. Например, макрос writefile, описанный в ^{параграфе 4.2.3}, может быть с успехом переписан в следующей, более изощренной форме:

Данная форма макроса, записывающего строку в файл, сначала временно переключается на секцию данных, используя при этом примитивную форму директивы SECTION, не модифицирующую __SECT__. Далее в секции данных объявляется строка и затем вызывается __SECT__, переключающий контекст на любую секцию, в которой пользователь работал до этого. Это исключает необходимость использования инструкции JMP (как в предыдущей версии макроса) для "перескакивания" данных, а также предотвращает возникновение ошибок в модуле OBJ формата, где пользователь потенциально может использовать различные секции кода.

6.1.1 ORG: Начало бинарного файла

Формат bin предусматривает дополнительную к списку ^{главы 5} директиву ORG. Функция этой директивы - задавать начальный адрес программы, с которого она располагается при загрузке в память.

Например, следующий код будет генерировать двойное слово 0x00000104:

В отличие от директивы ORG, применяемой MASM-совместимыми ассемблерами, которые позволяют перемещаться в объектном файле и переписывать уже сгенерированный код, NASM-овская ORG означает только то, что и соответствующее слово: origin (начало). Ее единственная функция - задавать смещение, которое будет прибавляться ко всем ссылкам на адреса внутри файла; она не допускает такого жульничества, как MASM. Дополнительные комментарии содержатся в ^{параграфе 10.1.3}.

6.1.2 bin-расширение директивы SECTION

Выходной формат bin расширяет директиву SECTION (или SEGMENT), позволяя вам указывать требования к выравниванию сегментов. Это делается путем добавления в конец строки определения секции спецификатора ALIGN. Например, строка

переключается на секцию .data и также указывает, что эта секция должна быть выровнена в памяти по границе параграфа.

Спецификатор ALIGN указывает, сколько младших бит в начальном адресе секции должны быть установлены в ноль. Указываемое значение выравнивания может быть любой степенью двойки.

6.2.1 obj-расширения директивы SEGMENT

Выходной формат obj расширяет директиву SEGMENT (или SECTION), позволяя задавать различные характеристики определяемого сегмента. Это делается путем добавления в конец строки определения сегмента дополнительных спецификаторов. Например,

определяет сегмент code, объявляя его при этом закрытым и требуя, чтобы код этого модуля был выровнен по границе параграфа.

Имеются следующие спецификаторы:

PRIVATE, PUBLIC, COMMON и STACK задают комбинацию характеристик сегмента. Сегменты PRIVATE не могут быть связаны компоновщиком с любыми другими; сегменты PUBLIC и STACK на стадии компоновки объединяются; сегменты COMMON накладываются друг на друга, вместо того, чтобы следовать друг за другом.
ALIGN используется, как уже упоминалось, для указания того, сколько младших бит в стартовом адресе сегмента должно быть установлено в 0. Значение выравнивания может быть любой степенью двойки от 1 до 4096; реально поддерживаются только значения 1, 2, 4, 16, 256 и 4096, поэтому если указать 8, оно будет округлено до 16, а 32, 64 и 128 будут округлены до 256 и т.д. Имейте в виду, что выравнивание по 4096-битной границе является PharLap-расширением формата и может не поддерживаться некоторыми компоновщиками.
CLASS используется для указания класса сегмента; этот спецификатор указывает компоновщику, что сегменты одного и того же класса должны быть расположены в выходном файле рядом друг с другом. Имя класса может быть любым словом, например CLASS=CODE.
OVERLAY, как и CLASS, имеет аргумент в виде произвольного слова и предоставляет компоновщику (способному на это) оверлейную информацию.
Сегменты могут быть объявлены как USE16 или USE32, что непосредственным образом влияет на объектный файл, а также заставляет NASM при ассемблировании такого сегмента переключаться на 16- или 32-битный режим соответственно.
При создании объектных файлов OS/2 вы должны объявлять 32-битные сегменты как FLAT, при этом базовый сегмент по умолчанию приписывается к специальной группе FLAT, а также определяет эту группу, если она еще не существует.
Формат obj позволяет также объявлять сегменты с предопределенными абсолютными адресами, несмотря на то, что компоновщики на данный момент не могут гибко использовать данную возможность; NASM все же позволяет вам объявить сегмент наподобие SEGMENT SCREEN ABSOLUTE=0xB800, если он вам нужен. Ключевые слова ABSOLUTE и ALIGN являются взаимоисключающими.

Атрибуты сегмента по умолчанию в NASM - это PUBLIC, ALIGN=1, без класса, без оверлея и USE16.

6.2.2 GROUP: Определение групп сегментов

Формат obj позволяет группировать сегменты, благодаря чему для ссылки на все сегменты группы может использоваться один сегментный регистр. NASM для этого поддерживает директиву GROUP. Вы можете написать:

При ассемблировании этого кода будет создана группа dgroup, содержащая сегменты data и bss. Как и в случае SEGMENT, имя директивы GROUP определяется как символ, поэтому вы можете ссылаться на переменную var в сегменте data как var wrt data или как var wrt dgroup, в зависимости от того, какое значение в данный момент находится в сегментном регистре.

Однако если вы ссылаетесь на var, объявленную в сегменте группы, NASM по умолчанию предоставляет смещение относительно начала группы, а не сегмента. Вследствие этого SEG var также будет возвращать базу группы, а не базу сегмента.

NASM позволяет сегменту являться частью более одной группы, однако при этом он будет выдавать предупреждение. Переменные, объявленные в таком сегменте, по умолчанию будут относиться к первой включающей данный сегмент группе.

Группа может не иметь ни одного сегмента; однако при этом вы можете делать WRT ссылки на группу, которая не содержит нужную переменную. OS/2, например, определяет специальную группу FLAT без всяких сегментов.

6.2.3 UPPERCASE: Отключение чувствительности к регистру

В отличие от NASM, некоторые OMF компоновщики нечувствительны к регистру символов; вследствие этого иногда полезно заставлять NASM генерировать объектные файлы в одном регистре. Директива формата UPPERCASE перед записью в объектный файл переводит имена всех сегментов, групп и символов в верхний регистр. В пределах исходного файла NASM остается регистро-чувствительным; однако объектные файлы, если это необходимо, могут быть составлены целиком в верхнем регистре.

UPPERCASE должна оставаться единственной в строке; она не требует никаких параметров.

6.2.4 IMPORT: Импортирование символов из DLL

Директива IMPORT определяет символ, импортируемый из DLL и используемый например для написания в NASM библиотеки импорта. При использовании директивы IMPORT вы должны объявить символ как EXTERN.

Директива IMPORT требует указания двух параметров, разделенных пробелом и являющихся соответственно именем импортируемого символа и именем библиотеки, из которой он импортируется. Например:

Третьим (необязательным) параметром является имя, под которым импортируемый символ известен в соответствующей библиотеке. Этот параметр применяется в том случае, если вы хотите, чтобы имя символа, используемое внутри вашего кода, не совпадало с именем того же символа в библиотеке. Например:

6.2.5 EXPORT: Экспортирование символов в DLL

Директива EXPORT определяет глобальный символ, экспортируемый как DLL-символ в создаваемую DLL (если вы пишете DLL в NASM). Чтобы использовать директиву EXPORT, вы должны объявить символ как GLOBAL.

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

Для определения атрибутов экспортируемого символа могут быть заданы дополнительные параметры. Эти параметры, как и второй, отделяются друг от друга пробелами. Если дополнительные параметры задаются, внешнее имя также должно указываться, неважно, совпадает ли оно с внутренним или нет. Имеются следующие дополнительные атрибуты:

resident указывает, что экспортируемое имя должно быть оставлено системным загрузчиком резидентным. Это делается для оптимизации часто используемых символом, импортируемых по имени.
nodata указывает, что экспортируемый символ является функцией, не использующей никаких неинициализированных данных.
parm=NNN, где NNN целое, устанавливает число параметров-слов в случае, если символ является вызовом-переходом между 32- и 16-битными сегментами.
Атрибуты в виде числа указывают, что символ должен экспортироваться с идентификационным номером (ординалом) и представляют собой собственно этот номер.

Например:

6.2.6 ..start: Определение точки входа в программу

OMF-компоновщики требуют, чтобы один из компонуемых объектных файлов определял точку входа в программу (место, откуда начнется выполнение программы после загрузки). Если этот файл ассемблируется при помощи NASM, вы можете указать точку входа путем объявления в этом месте специального символа ..start.

6.2.7 obj-расширения директивы EXTERN

Если вы объявляете внешний символ директивой

то ссылки наподобие mov ax,foo будут давать вам смещение foo относительно базы его предопределенного сегмента (как задано в модуле, где определен foo). Таким образом, доступ к содержимому foo вы будете обычно осуществлять следующим образом

Это получается немного громоздко, особенно если вы знаете, что внешний символ будет доступен из данного сегмента или группы (например, dgroup). Так, если DS уже содержит dgroup, вы можете написать

Однако необходимость каждый раз это печатать для получения доступа к foo очень утомительна; NASM позволяет вам объявить foo в альтернативной форме

Эта форма заставляет NASM делать вид, что базовым сегментом foo на самом деле является dgroup; так, выражение seg foo теперь будет возвращать dgroup, а выражение foo будет эквивалентно foo wrt dgroup.

Описанный WRT-механизм может быть использован для "проявления" внешних символов по отношению к любой группе или сегменту в программе. Он также может быть применен к общим переменным (см. ^{параграф 6.2.8} ниже).

6.2.8 obj-расширения директивы COMMON

Формат obj позволяет общим переменным быть как ближними, так и дальними; NASM обеспечивает этот механизм при помощи следующего синтаксиса:

Дальние общие переменные могут иметь размер больше 64 Кб, поэтому спецификация OMF говорит, что они объявляются как число элементов данного размера. Так, 10-байтная дальняя переменная должна быть объявлена как 10 однобайтных элементов, 5 двухбайтных, 2 пятибайтных или 1 десятибайтный элемент.

Некоторые OMF-компоновщики при разрешении общих переменных, объявленных более чем в одном модуле, требуют совпадения размеров элемента и переменной. Поэтому NASM должен позволять задавать размер элемента дальних переменных. Он делает это при помощи следующего синтаксиса:

Если размер элемента не задан, он предполагается по умолчанию равным 1. Не требуется также и явное указание ключевого слова FAR, так как только дальние общие переменные могут иметь размер элемента. Исходя из этого, приведенные выше объявления будут эквивалентны следующим:

В дополнение ко всему вышесказанному, директива COMMON в obj поддерживает также и спецификацию WRT-умолчаний наподобие тому, как это работает для EXTERN (см. ^{параграф 6.2.7}). Поэтому вы можете объявлять такие, например, вещи:

6.3.1 win32-расширения директивы SECTION

Как и формат obj, win32 позволяет вам указывать в строке с директивой SECTION дополнительную информацию, предназначенную для управления типом и свойствами определяемой секции. Обычно тип секции и ее свойства для стандартных имен .text, .data и .bss генерируются NASM автоматически, но при помощи приведенных спецификаторов могут быть и переопределены.

Имеются следующие спецификаторы:

code или text (что эквивалентно) описывает секцию как секцию кода. При этом секция маркируется как читаемая и выполняемая, но не записываемая; компоновщику указывается также, что тип секции - код.
data и bss, по аналогии с code, определяют секцию данных. Секция данных маркируется как читаемая и записываемая, но не выполняемая. Спецификатор data объявляет секцию инициализированных данных, в то время как спецификатор bss - неинициализированных.
info описывает секцию как информационную, не включаемую компоновщиком в исполнимый файл, но способную (например) передать компоновщику информацию. Например, объявление info-секции с именем .drectve побуждает компоновщик интерпретировать ее содержание как опции командной строки.
align= с последующим числом описывает требования к выравниванию секции. Максимум, что вы можете задать - 64: объектный формат Win32 не имеет способа запросить выравнивание большее, чем это. Если выравнивание явно не указано, для секций кода используется выравнивание по параграфам, а для секций данных - по двойным словам. Информационные секции получают по умолчанию выравнивание в 1 байт (т.е. нет его), даже если значение указано явно.

Если вы не укажете ни одного описанного выше спецификатора, NASM принимает следующие значения по умолчанию:

Любые другие имена секций обрабатываются так же, как и .text.

6.5.1 elf-расширения директивы SECTION

Как и формат obj, elf позволяет вам указывать в строке с директивой SECTION дополнительную информацию, предназначенную для управления типом и свойствами определяемой секции. Обычно тип секции и ее свойства для стандартных имен .text, .data и .bss генерируются NASM автоматически, но при помощи приведенных спецификаторов могут быть и переопределены.

Имеются следующие спецификаторы:

alloc описывает секцию, которая при запуске программы загружается в память. noalloc описывает незагружаемые секции, такие как информационные или секции комментариев.
exec описывает секцию, которая при запуске программы может выполняться (разрешено ее выполнение). Секции noexec выполняться не могут.
write описывает секцию, в которую после запуска программы разрешается запись. В секции nowrite запись запрещена.
progbits описывает секцию, явно сохраняемую в объектном файле: обычно это секции кода и инициализированных данных. nobits описывает секции, не присутствующие в файле, такие как BSS (неинициализированных данных).
align= с последующим числом, как и obj, задает параметр выравнивания секции.

Если вы не укажете ни одного описанного выше спецификатора, NASM принимает следующие значения по умолчанию:

(Любые секции, не являющиеся .text, .data или .bss обрабатываются так же, как и секция other).

6.5.2 Позиционно-независимый код: Специальные символы формата elf и WRT

Спецификация ELF содержит достаточное число возможностей написания позиционно-независимого кода (PIC), благодаря которым разделяемые библиотеки ELF весьма гибкие. Однако это также означает, что NASM должен быть способен генерировать разнообразные замысловатые типы релокейшнов объектных ELF-файлов.

Так как ELF не поддерживает сегментные ссылки, оператор WRT для своей обычной цели не используется; вместо этого формат elf использует WRT для других целей, а именно для специальных PIC-типов перемещений.

elf определяет пять специальных символов, которые вы можете использовать с правой стороны оператора WRT для получения PIC-типов перемещений. Это ..gotpc, ..gotoff, ..got, ..plt и ..sym. Их функции описаны ниже:

Ссылка на символ, помеченный как база глобальной таблицы смещений (GOT) при помощи wrt ..gotpc, будет в результате давать расстояние от начала текущей секции до глобальной таблицы смещений. (Для ссылки на GOT используется обычно стандартный символ _GLOBAL_OFFSET_TABLE_). Таким образом, для получения реального адреса GOT, вам необходимо прибавить к результату конструкцию $$.
Ссылка на определенную позицию в одной из ваших собственных секций при помощи wrt ..gotoff будет давать расстояние от начала GOT до заданной позиции, поэтому прибавив это расстояние к адресу GOT, вы получите реальный адрес нужной вам позиции.
Ссылка на внешний или глобальный символ при помощи wrt ..got заставляет компоновщик построить элемент GOT, содержащий адрес символа, поэтому ссылка дает расстояние от начала GOT до этого элемента. Таким образом, прибавляя к полученной ссылке адрес GOT, вы получите адрес, по которому содержится адрес символа.
Ссылка на имя процедуры при помощи wrt ..plt заставляет компоновщик построить элемент таблицы компоновки процедуры (PLT) и ссылка в результате дает адрес элемента PLT. Вы можете использовать это обычно только в контексте создания относительных перемещений (т.е. цели для CALL или JMP), так как ELF абсолютно не имеет перемещаемых типов для ссылки на элементы PLT.
Ссылка на имя символа при помощи wrt ..sym заставляет NASM записать обычное перемещение, однако вместо того, чтобы сделать перемещение относительным к началу секции и затем добавить смещение символа, он создаст запись смещения непосредственно к запрашиваемому символу. Различие необходимо из-за особенностей динамического компоновщика.

Более полное объяснение использования типов перемещений для написания в NASM разделяемых библиотек дано в ^{параграфе 8.2}.

6.5.3 elf-расширения директивы GLOBAL

Объектные файлы ELF могут содержать больше информации о глобальном символе, чем просто его адрес: они могут содержать размер символа, а также его тип. Это сделано не только для удобства при отладке, это просто необходимо, если программа пишется в виде разделяемой библиотеки. Для задания дополнительной информации NASM поддерживает некоторые расширения директивы GLOBAL.

Поставив после имени глобальной переменной двоеточие и написав function или data (object является синонимом data), вы можете указать, чем является глобальная переменная - функцией или объектом данных. Например, строка

экспортирует глобальный символ hashlookup как функцию, а hashtable - как объект данных.

После ввода спецификатора вы можете также указать в виде числового выражения (которое может включать метки и даже опережающие ссылки) размер ассоциированных с символом данных, например:

Это заставит NASM автоматически подсчитать длину таблицы и поместить эту информацию в символьную таблицу ELF.

Объявление типа и размера глобальных символов требуется при написании разделяемых библиотек. Дополнительную информацию вы можете найти в ^{параграфе 8.2.4}.

6.5.4 elf-расширение директивы COMMON

ELF позволяет задавать требования к выравниванию общих переменных. Это делается путем помещения числа (которое должно быть степенью двойки) после имени и размера общей переменной и отделения этого числа (как обычно) двоеточием. Например, массив двойных слов, который должен быть выровнен по двойным словам:

Эта строка объявляет массив размером 128 байт и требует, чтобы он был выровнен по 4-байтной границе.

6.9.1 Требование библиотеки: Директива LIBRARY

RDOFF содержит механизм "требования библиотеки", которая будет связана с модулем как во время загрузки, так и при выполнении. Это осуществляется директивой LIBRARY, которая принимает один аргумент, являющийся именем модуля:

7.1.1 Использование формата obj для получения .EXE файлов

В данном параграфе описан обычный способ создания .EXE файлов путем компоновки друг с другом .OBJ файлов.

Большинство 16-битных языков программирования поставляются с собственным компоновщиком; если у вас нет ни одного, возьмите с "ftp://x2ftp.oulu.fi/pub/msdos/programming/lang/" свободно распространяемый компоновщик VAL, упакованный в формате LZH. LZH-архиватор можно найти на "ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers". На "http://www.pcorner.com/tpc/old/3-101.htm" имеется еще один бесплатный компоновщик FREELINK (только он без исходников), и наконец, на "http://www.delorie.com/djgpp/16bit/djlink/" можно взять компоновщик djlink, написанный DJ Delorie.

При компоновке нескольких .OBJ файлов в один .EXE файл вы должны убедиться, что только один из них (.OBJ) имеет точку входа (при помощи специального символа ..start, определяемого obj форматом: см. ^{параграф 6.2.6}). Если ни один из модулей не определяет точки входа, компоновщик не будет знать, какое значение записать в заголовок выходного файла в качестве стартового адреса; если же точка входа определена в нескольких файлах, компоновщик не сможет понять, какое именно значение использовать.

Здесь приводится пример исходного файла, который ассемблируется NASMом в .OBJ файл и им же компонуется в .EXE. На этом примере продемонстрированы основные принципы определения стека, инициализации сегментных регистров и объявления точки входа. Данный файл содержится также в подкаталоге test NASM-архивов под именем objexe.asm.

Эта инициализационная часть кода устанавливает DS на сегмент данных и инициализирует SS и SP для указания на вершину стека. Заметьте, что после записи в SS прерывания неявно запрещаются на время выполнения следующей команды, в качестве которой подразумевается загрузка SP. Это необходимо для корректной инициализации стека.

Заметьте также, что в начале данного кода определен символ ..start, который в результирующем исполнимом файле будет являться точкой входа.

Здесь начинается основная программа: загрузка в DS:DX указателя на приветствующее сообщение (hello является неявной ссылкой на сегмент data, загруженный в DS настроечным кодом, поэтому полный указатель корректен) и вызов DOS-функции вывода строки на экран.

Здесь программа завершается при помощи другого системного DOS-вызова.

Сегмент данных содержит строку, которую нужно отобразить на экране.

Данный код объявляет сегмент стека, содержащий 64 байта неинициализированного стекового пространства, где символ stacktop указывает на его вершину. Директива segment stack stack определяет сегмент под именем stack, тип которого также STACK. В нашем случае не требуется дальнейшее выполнение программы, но если в ней не определить сегмент STACK, компоновщики вероятнее всего выдадут предупреждение или сообщение об ошибке.

Приведенный выше файл будет ассемблироваться в .OBJ файл, затем компоноваться NASM в корректный .EXE файл, который при запуске будет выводить на экран строку 'Привет, фуфел!' и затем завершаться.

7.1.2 Использование формата bin для получения .EXE файлов

Формат .EXE является достаточно простым, поэтому построение .EXE файлов возможно путем написания чисто бинарной программы с последующим помещением в ее начало 32-битного заголовка. Структура заголовка несложная, поэтому он может быть создан обычными командами DB и DW. Исходя из вышесказанного, для непосредственного создания .EXE файлов может быть использован формат bin.

В архиве NASM имеется подкаталог misc, в котором находится файл макросов exebin.mac. В этом файле определены три макроса: EXE_begin, EXE_stack и EXE_end.

Для создания файла при помощи формата bin вы должны включить в свой исходный файл директиву %include exebin.mac, загружающую в него пакет требуемых макросов. Затем для генерации заголовка файла вы должны выполнить макрокоманду EXE_begin (не имеет аргументов). После этого следует обычный для формата bin код программы - вы можете использовать все три стандартные секции .text, .data и .bss. В конце файла вы должны вызвать макрос EXE_end (без аргументов), который для маркировки размеров секции определяет некоторые символы, ссылающиеся на заголовок кода, сгенерированный макросом EXE_begin.

В данной модели написанный вами код стартует с адреса 0x100, как и обычный .COM файл - в действительности, если вы удалите 32-битный заголовок из сгенерированного .EXE файла, то получите работающую .COM программу. Все базы сегментов в полученном файле одинаковы, поэтому размер программы ограничен 64К (опять же, как и .COM файл). Имейте в виду, что директива ORG используется макросом EXE_begin, поэтому вы не должны применять ее самостоятельно.

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

При запуске полученного .EXE файла пара SS:SP настраивается на указание вершины 2Кб стека. Вызвав макрос EXE_stack, вы можете изменить размер стека по умолчанию. Например, для изменения размера стека вашей программы до 64 байт вы должны вызвать EXE_stack 64.

В подкаталоге архива NASM содержится простая программа binexe.asm, из которой .EXE файл создается вышеописанным способом.

7.2.1 Использование формата bin для получения .COM файлов

.COM файлы загружаются в свой сегмент по смещению 100h (сегмент может меняться). Выполнение начинается с адреса 100h, т.е. программа по этому адресу стартует. Таким образом, при написании .COM программы ваш исходный файл должен выглядеть наподобие следующего:

Формат bin помещает секцию .text в начале файла, поэтому вы можете объявлять данные или BSS перед написанием собственно кода.

Секция BSS (неинициализированные данные) не занимает места в самом .COM файле: вместо этого адреса BSS-элементов разрешаются относительно адреса конца файла, т.е. при запуске программы это пространство будет являться свободной памятью, поэтому вы не должны предполагать, что оно будет заполнено нулями или чем-либо еще - там находится просто мусор.

Для ассемблирования приведенной выше программы вы должны использовать следующую командную строку:

Если явно не указать имя выходного файла, формат bin создаст файл с именем myprog; в этом случае вы можете просто переименовать его так, как вам нужно.

7.2.2 Использование формата obj для получения .COM файлов

Если вы пишете .COM программу с применением более одного модуля, то возможно захотите ассемблировать несколько .OBJ файлов и затем собрать их в одну программу. Вы можете это сделать двумя путями: при помощи компоновщика, способного непосредственно создавать .COM файлы (TLINK это может) или применив конвертер EXE2BIN для преобразования .EXE файла, полученного на выходе компоновщика, в .COM файл.

Если вы это делаете, вам нужно позаботиться о нескольких вещах:

Кодовый сегмент первого объектного файла должен начинаться со строки вида RESB 100h. Это гарантирует начало кода по смещению 100h относительно начала сегмента, так чтобы компоновщик или программа конвертации не корректировали адресные ссылки при генерации .COM файла. Другие ассемблеры для данной цели используют директиву ORG, однако в NASM ORG является дополнительной директивой выходного формата bin и не означает то же самое, что в MASM-совместимых ассемблерах.
Вам не нужно определять сегмент стека.
Все ваши сегменты должны быть в одной и той же группе, чтобы все смещения на символы как в коде, так и в данных были смещениями относительно одной и той же базы сегмента. Это нужно для того, чтобы при загрузке .COM файла все сегментные регистры содержали одно и то же значение.

7.4.1 Внешние символьные имена

Компиляторы С имеют соглашения, в соответствии с которыми имена всех глобальных символов (функций или данных) образуются путем префиксирования имени из С-программы символом подчеркивания. Так, например, функция, о которой С-программист думает как о printf, для программиста на ассемблере является _printf. Это означает, что в своей ассемблерной программе вы можете определять символы без лидирующего знака подчеркивания, не боясь при этом, что они случайно совпадут с именами С-символов.

Если вам неудобно использовать знаки подчеркивания, вы можете определить макросы для замены директив GLOBAL и EXTERN следующим образом:

(Данные формы макросов принимают только один аргумент; если вам требуется больше, используйте конструкцию %rep).

Если вы определите внешний символ как

макрос развернет его в следующие строки:

Thereafter, you can reference printf as if it was a symbol, and the preprocessor will put the leading underscore on where necessary.

После этого вы можете ссылаться на printf, а препроцессор, где это нужно, будет помещать ведущий знак подчеркивания. Макрос cglobal работает точно также.

7.4.2 Модели памяти

NASM прямо не поддерживает механизма различных моделей памяти, реализованных в С; вы должны отслеживать это самостоятельно. Это означает, что вы должны учитывать следующее:

В моделях, имеющих один сегмент кода (tiny, small и compact), функции являются ближними. Это значит, что указатели на функции при сохранении в сегменте данных или помещении в стек являются 16-битными и содержат только поле смещения (регистр CS никогда не изменяет свое значение и всегда содержит сегментную часть полного адреса функции) и что такие функции вызываются инструкцией near CALL и возврат из них производится при помощи RETN (что в NASM является синонимом RET). Следовательно, вы должны писать свои подпрограммы с использованием RETN, а также вызывать внешние С-подпрограммы при помощи ближней инструкции CALL.
В моделях, использующих более одного сегмента кода (medium, large и huge), функции являются дальними. Это значит, что длина указателей функций составляет 32 бита (16 бит смещение и 16 бит сегмент) и что функции вызываются при помощи CALL FAR (или CALL seg:offset) и возврат из них производится при помощи RETF. При использовании таких моделей вы должны писать свои подпрограммы так, чтобы возврат из них производился по RETF, а внешние подпрограммы вызывать при помощи CALL FAR.
В моделях, использующих единственный сегмент данных (tiny, small и medium), указатели на данные являются 16-битными, содержащими только поле смещения (регистр DS не изменяет своего значения и всегда представляет сегментную часть полного адреса).
В моделях, использующих более одного сегмента данных (compact, large и huge), длина указателей на данные составляет 32 бит, 16 бит из которых является смещением, а другие 16 бит - сегментом. Вы должны стараться в своих подпрограммах не модифицировать DS без необходимости, а после модификации - всегда восстанавливать. В то же время регистр ES свободен и вы можете использовать его для доступа к содержимому, на которое ссылается 32-битный указатель.
Модель памяти huge позволяет одиночным элементам данных превышать размер 64К. В любых других моделях вы можете получить доступ ко всем элементам данных простым арифметическим манипулированием переданного поля смещения (неважно, присутствует поле сегмента или нет). В модели памяти huge к вычислению указателей надо подходить более тщательно.
В большинстве моделей памяти имеется сегмент данных по умолчанию, сегментный адрес которого хранится в DS на протяжении всего выполнения программы. Этот сегмент данных обычно совпадает с сегментом стека, хранящемся в SS, поэтому и локальные переменные функций (хранящиеся в стеке), и глобальные элементы данных могут быть легко доступны без изменения DS. Большие элементы данных обычно хранятся в других сегментах. Однако некоторые модели памяти (хотя обычно они нестандартные) используют SS и DS по другому. Будьте внимательны в этом случае по отношению к локальным переменным функций.

В моделях с единственным сегментом кода этот сегмент называется _TEXT, поэтому ваш сегмент должен иметь то же самое имя для компоновки его в то же место, что и основной сегмент кода. В моделях с единственным сегментом данных или с сегментом данных по умолчанию последний именуется как _DATA.

7.4.3 Определения и вызовы функций

Соглашения по вызовам С в 16-битных программах описываются ниже.

Вызывающая программа помещает параметры функции в стек один за другим в обратном порядке следования (так что первый аргумент функции помещается в стек последним).
Вызывающая программа выполняет инструкцию CALL для передачи управления подпрограмме. Эта инструкция в зависимости от модели памяти может быть как ближней, так и дальней.
Подпрограмма получает управление и обычно (несмотря на то, что это не требуется в функциях, которым не нужен доступ к своим параметрам) начинается с сохранения SP в BP с целью дальнейшего использования BP в качестве базы указателя для нахождения параметров в стеке. Однако частью соглашений о вызовах является сохранение содержимого BP любой функцией С. Следовательно подпрограмма, если она использует BP как указатель кадра, должна предварительно поместить в стек его содержимое.
Подпрограмма может получить свои параметры через BP. Слово [BP] хранит предыдущее значение BP, помещенное в стек; следующее слово, [BP+2], хранит смещение адреса возврата, помещенное в стек инструкцией CALL. В ближних функциях после этого ([BP+4]) начинаются параметры; в дальных функциях по адресу [BP+4] находится сегментная часть адреса возврата и параметры начинаются с [BP+6]. Самый левый параметр функции доступен по смещению из BP, т.к. в стек он был помещен последним; следующие параметры соответственно доступны по следующим смещениям. Таким образом, в функциях с переменным числом параметров, подобных printf, помещение параметров в стек в обратном порядке означает, что функция знает, где находится ее первый параметр, сообщающий число и тип оставшихся параметров.
Подпрограмма после этого может увеличить значение SP, например для распределения места в стеке для локальных переменных, которые после этого будут доступны по отрицательным смещениям от BP.
Подпрограмма, если она возвращает значение вызывающей программе, должна передавать это значение в AL, AX или DX:AX в зависимости от размера последнего. Результаты, являющиеся числами с плавающей точкой иногда (в зависимости от компилятора) возвращаются в регистре сопроцессора ST0.
Как только подпрограмма завершит свою работу, она восстанавливает значение SP из BP (если она распределяла локальное пространство стека), затем изымает из стека предыдущее значение BP и в зависимости от модели памяти возвращается в вызвавшую программу через RETN или RETF.
Когда вызывающая программа возвратит себе управление, параметры функции остаются в стеке, поэтому для удаления их к SP обычно прибавляется непосредственная константа (вместо выполнения серии медленных инструкций POP). Поэтому если функция случайно (например, из-за несоответствия прототипов) будет вызвана с неверным числом параметров, стек при возврате останется в осмысленном состоянии, т.к. вызвавшая программа, которая знает, сколько параметров она поместила в стек, удалит их.

Поучительно сравнить данное соглашение о вызовах с программами на Паскале (см. ^{параграф 7.5.1}). Паскаль имеет более простое соглашение, т.к. в нем нет функций с переменным числом параметров и подпрограмма знает, сколько параметров ей передается и способна самостоятельно удалить их из стека путем указания в инструкциях RET или RETF непосредственного значения. Параметры помещаются в стек слева-направо, а не справа-налево как в С, поэтому компилятор может дать лучшую гарантию последовательности выполнения без снижения производительности.

Исходя из вышесказанного, вы можете определить С-подобную функцию следующим образом (в примере использована модель памяти small):

Для больших моделей памяти вы должны заменить RET в данной функции на RETF и брать первый параметр не из [BP+4], а из [BP+6]. Естественно, если один из параметров будет указателем, смещения следующих параметров будут зависеть от модели памяти: дальние указатели занимают в стеке 4 байта, в то время как короткие - два.

Если посмотреть с другой стороны, то для вызова С-функции из вашего ассемблерного кода вы должны сделать что-то наподобие следующего:

Этот ассемблерный код, использующий модель памяти small, эквивалентен С-коду

В больших моделях памяти кодирование функции вызова выглядит похоже, но все-таки несколько отличается. В приведенном ниже примере подразумевается, что регистр DS уже содержит базу сегмента _DATA. Если это не так, вы должны его проинициализировать.

Целое число по прежнему будет занимать в стеке одно слово, так как большая модель памяти не влияет на размер типа данных int. В то же время первый аргумент для printf (помещаемый в стек последним), является указателем и поэтому состоит из двух частей - сегмента и смещения. Сегмент должен сохраняться в памяти вторым, поэтому в стек он помещается первым. (Конечно PUSH DS будет иметь более короткую инструкцию, чем PUSH WORD SEG mystring, если DS инициализирован так, как подразумевается в приведенном примере). Затем следует дальний вызов call far, как это определено для больших моделей памяти; после возврата из подпрограммы регистр стека увеличивается на 6 (а не на 4) с целью коррекции на размер дополнительного слова, помещенного туда ранее.

7.4.4 Доступ к элементам данных

Для получения доступа к переменным С или объявления переменных, к которым С в свою очередь может обратиться, вы должны всего лишь объявить имена как EXTERN или GLOBAL соответственно. (Имена требуют лидирующего знака подчеркивания, см. ^{параграф 7.4.1}.) Таким образом, объявленная в С переменная int i может быть доступна из ассемблера как

Чтобы объявить собственную целую переменную, к которой С-программа сможет обратиться как extern int j, вы должны сделать следующее (убедитесь, что эта переменная находится в сегменте _DATA):

Для получения доступа к С-массиву вам нужно знать размер компонетов последнего. Например, переменные типа int имеют размер два байта (слово), поэтому если С-программа объявляет массив как int a[10], вы можете обратиться к элементу a[3] при помощи инструкции mov ax,[_a+6]. (Байтовое смещение 6 получено путем умножения индекса 3 требуемого элемента на размер элементов массива 2). Размеры базовых типов С для 16-битных компиляторов: 1 для char, 2 для short и int, 4 для long и float, 8 для double.

Чтобы получить доступ к структуре данных С, вам необходимо знать смещение интересующего вас поля от базы этой структуры. Вы можете сделать это либо преобразовав определение С-структуры в определение NASM-структуры (при помощи STRUC), либо рассчитать это смещение и использовать его "как есть".

Чтобы правильно использовать структуры С, вы должны изучить руководство по вашему С-компилятору, чтобы знать, как он организует структуры данных. NASM не делает специального выравнивания для членов его собственных структур STRUC, поэтому если С-компилятор делает это, вы можете задать такое смещение самостоятельно. Обычно вы можете предположить, что структура наподобие

будет иметь длину 4 байта, а не 3, так как поле int выравнивается по двухбайтной границе. Однако такие особенности имеют тенденцию конфигурироваться компилятором С при помощи ключей командной строки, либо директив #pragma, поэтому вы должны выяснить, как именно это делает ваш компилятор.

7.4.5 c16.mac: Макросы для 16-битного C-интерфейса

В подкаталоге misc архива NASM имеется файл макросов c16.mac. В нем определены три макроса: proc, arg и endproc. Они предназначены для использования в определениях С-подобных процедур и автоматизируют большинство работ по слежению за соблюдением соглашения о вызовах.

Ниже приведен пример ассемблерной функции, использующей этот набор макросов:

Здесь определяется процедура _nearproc, принимающая два аргумента, первый (i) - это целое и второй (j) - указатель на целое. Процедура возвращает i + *j.

Заметьте, что макрос arg при его разворачивании содержит в первой строке EQU, которая в результате определяет %$i как смещение от BP. При этом используются контекстно-локальные переменные (локальные к контексту, сохраняемому в контекстном стеке макросом proc и удаляемому оттуда макросом endproc), поэтому в других процедурах может быть использовано то же самое имя аргумента. Конечно, вы можете этого не делать.

По умолчанию представленный набор макросов создает код для ближних функций (модели памяти tiny, small и compact). Чтобы генерировать код для дальних функций (модели medium, large и huge), вы должны определить %define FARCODE. Данное определение изменяет тип возвращаемой endproc инструкции, а также начальную точку смещения аргументов. Набор макросов совершенно не зависит от того, являются ли указатели данных дальними или нет.

Макрос arg может принимать дополнительный параметр, представляющий собой размер аргумента. Если размер не задан, по умолчанию принимается 2, т.к. большинство параметров функций вероятно будут иметь тип int.

Эквивалент представленной выше функции для модели памяти large будет таким:

Так как j теперь будет дальним указателем, в этом примере используется аргумент макроса arg, определяющий параметр размером 4. Когда мы читаем значение по адресу j, мы должны загрузить как смещение, так и сегмент.

7.5.1 Соглашение о вызовах в Pascal

Ниже описываются соглашения о вызовах в 16-битных Паскаль-программах.

Вызывающая программа помещает параметры функции в стек один за другим в обычном порядке (слева-направо, так что первый аргумент функции помещается также первым).
Вызывающая программа для передачи управления подпрограмме выполняет дальнюю инструкцию CALL.
Подпрограмма получает управление и обычно (несмотря на то, что это не требуется в функциях, которым не нужен доступ к своим параметрам) начинается с сохранения SP в BP с целью дальнейшего использования BP в качестве базы указателя для нахождения параметров в стеке. Однако частью соглашений о вызовах является сохранение содержимого BP любой функцией. Следовательно подпрограмма, если она использует BP как указатель кадра, должна предварительно поместить в стек его содержимое.
Подпрограмма может получить доступ к своим параметрам относительно BP. Слово [BP] адресует в стеке предыдущее значение BP. Следующее слово, [BP+2], адресует смещение адреса возврата, а [BP+4] - сегмент адреса возврата. Параметры начинаются со смещения [BP+6]. По этому смещению от BP доступен самый "правый" параметр функции, так как в стек он был помещен последним; следующие параметры идут соответственно по более большим смещениям.
В процессе выполнения подпрограмма может увеличить значение SP с целью выделения в стеке места под свои локальные переменные. Эти переменные будут доступны по отрицательным от BP смещениям.
Подпрограмма должна передавать результат выполнения назад в вызвавшую программу через AL, AX или DX:AX, в зависимости от размера значения. Результаты в виде чисел с плавающей точкой возвращаются через регистр ST0. Результаты типа Real (собственные типы Борланда - числа с плавающей точкой, прямо не обрабатываемые в FPU) возвращаются в группе DX:BX:AX. Чтобы возвратить результат типа String, вызывающая программа перед помещением в стек параметров помещает туда указатель на временную строку, а подпрограмма по этому адресу возвращает строковое значение. Указатель не является параметром и не должен удаляться из стека инструкцией RETF.
Когда подпрограмма заканчивает свою работу, она восстанавливает содержимое SP из BP, достает из стека предыдущее значение BP и возвращается через RETF. Здесь используется форма RETF с непосредственным операндом, представляющим собой число байт, снимаемых с вершины стека в качестве параметров. Снятие параметров со стека - это побочный эффект инструкции возврата.
Дополнительных действий от вызвавшей программы не требуется, так как параметры функции при получении ей управления уже удалены из стека.

Исходя из вышесказанного, вы должны определить функцию в стиле Паскаль, принимающую два аргумента типа Integer, следующим образом:

С другой стороны, для вызова Паскаль-функции из вашего ассемблерного кода, вы должны сделать что-то вроде следующего:

Этот код эквивалентен следующим строкам на Паскале:

7.5.2 Ограничение имен сегментов в Borland Pascal

Так как внутренний формат модуля Borland Pascal полностью отличается от OBJ, при компоновке модуля с реальным OBJ файлом выполняется очень поверхностная работа по чтению и пониманию различной информации из последнего. Вследствие этого объектные файлы, предназначенные для компоновки с Паскаль-программами, должны удовлетворять нескольким ограничениям:

Процедуры и функции должны находиться в сегменте с именем CODE, CSEG, или заканчивающимся на _TEXT.
Инициализированные данные должны находиться в сегменте с именем CONST или заканчивающимся на _DATA.
Неинициализированные данные должны находиться в сегменте с именем DATA, DSEG, или заканчивающимся на _BSS.
Любые другие сегменты, имеющиеся в объектном файле, полностью игнорируются. Директивы GROUP и атрибуты сегментов также игнорируются.

7.5.3 Использование c16.mac с Pascal-программами

Пакет макросов c16.mac, описанный в ^{параграфе 7.4.5}, может быть также использован для облегчения написания функций, вызываемых из программ на Паскале. Для этого вам нужно определить %define PASCAL. Данное определение делает все функции дальними (это подразумевает FARCODE), а также генерирует инструкции возврата из подпрограммы в форме, имеющей операнд.

Определение PASCAL не изменяет код, рассчитывающий смещения аргументов; вы должны объявлять аргументы вашей функции в обратном порядке. Например:

Концептуально здесь определяется та же самая подпрограмма, что и в ^{параграфе 7.4.5} : функция принимает два аргумента, целое число и указатель на целое и возвращает сумму целого и содержимого, на которое ссылается указатель. Отличие между этим кодом и версией С для большой модели памяти состоит в том, что вместо FARCODE определяется PASCAL, а аргументы объявляются в обратном порядке.

8.1.1 Внешние символьные имена

Большинство 32-ух битных Си-компиляторов поддерживают конвенцию, используемую в 16-ти битных компиляторах: имена всех глобальных имен (функций или переменных) они определяют префиксом ⌠подчеркивание■ (например: extrn_link в Си будет _extrnlink в линкуемом файле), добавляемое к имени, действующем в Си-программе. Правда, не все это делают: спецификация ELF указывает, что все имена в Си-программе не имеют предваряющего подчеркивания в их эквивалентах на языке ассемблера.

Старый Си-компилятор в Линуксе a.out, все компиляторы для Win32, DJGPP, NetBSD и FreeBSD, все они используют предваряющее ⌠подчеркивание■; для этих компиляторов макросы cextern и cglobal, как они описаны в ^{параграфе 7.4.1}, будут работать. Для ELF, разумеется, предваряющее подчеркивание не используется.

8.1.2 Определение и вызов функций

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

Вызывающий код проталкивает параметры в стек один за другим в обратном порядке (справа налево, таким образом, первый объявленный аргумент функции будет помещен в стек последним).
Затем вызывающий код выполняет ближний вызов, чтобы передать управление вызываемой функции.
Вызываемая функция, получая управление, и обычно (хотя это не всегда необходимо в функциях, которые не обращаются к своим параметрам) начиная с сохранения значений ESP в EBP,чтобы можно было использовать EBP как базовый указатель для доступа к параметрам в стеке. Однако, вызывающий код возможно делает тоже самое (устанавливает EBP на свой стек), поэтому по этой части конвенции о вызове, состояние EBP должно быть сохранено во всех Си-функциях. Поэтому вызываемая функция, если она хочет установить EBP как указатель на свои параметры должна сначала сохранить в стеке его предыдущее значение.
Вызываемая функция может обращаться к своим параметрам относительно EBP. Двойное слово по адресу [EBP] содержит предыдущее значение EBP, т.к. оно было сохранено в стеке; следующее двойное слово по адресу [EBP+4] содержит адрес возврата, протолкнутый туда инструкцией CALL. После этого начинаются параметры - с адреса [EBP+8]. Самый левый параметр функции, т.к. он был помещен в стек последним, доступен по этому смещению от EBP; остальные расположены по бОльшим смещениям. Поэтому, в таких функциях как printf, которые имеют переменное число параметров, заталкивание параметров в обратном порядке позволяет функции узнать где находится первый параметр, в котором содержится информация о количестве и типах остальных.
Вызываемая функция также может уменьшить значение ESP для того, чтобы зарезервировать место в стеке для локальных переменных, которые будут доступны как отрицательные смещения относительно EBP.
Вызываемая функция, если она хочет вернуть значение вызывающему коду, должна оставить это значение в AL, AX или EAX, в зависимости от размера. Значения с плавающей запятой обычно возвращаются в ST0.
Как только вызываемая функция закончила свои основные действия, она восстанавливает ESP из EBP если она резервировала место в стеке, затем выталкивает предыдущее значение EBP, и возвращает управление через RET (эквивалентно, RETN).
Когда вызывающий код снова получает контроль от вызываемой функции, параметры функции все еще остаются в стеке, поэтому обычно к значению ESP прибавляется непосредственное значение, чтобы убрать их (вместо выполнения нескольких медленных инструкций POP). Поэтому, если функция случайно будет вызвана с неверным числом параметров, т.е. не соответствующем прототипу, стек будет возвращен вызывающим кодом в то состояние, в котором он находился до вызова этой функции, который знает сколько параметров было помещено в стек, и удаляет их оттуда.

Существует альтернативная конвенция вызова, используемая в Win32 программах для вызовов через Windows API, а также для функций, вызываемых Windows API, таких как оконные процедуры (window procedures): они описаны так, чтобы использовать Microsoft __stdcall конвенцию. Это очень похоже на конвенцию Паскаля, в вызываемой функции очищаются параметры из стека, используя параметр с инструкцией RET. Однако, параметры также передаются справа налево.

Если вы определите функцию в стиле языка Си следующим образом:

С другой стороны, чтобы вызывать Си-функцию из вашего ассемблерного кода, вы должны сделать что-то вроде этого:

Этот фрагмент кода - ассемблерный эквивалент Си-кода

8.1.3 Доступ к переменным

Чтобы получить доступ к Си-переменным, или чтобы объявить переменные, к которым может обращаться Си, вам достаточно объявить имена как GLOBAL или EXTERN. (Опять же, имена нужно предварять подчеркиванием, как это описано в ^{параграфе 8.1.1}.) Таким образом, Си-переменные, объявленные как int i могут быть доступны из ассемблера как

И чтобы объявить ваши собственные переменные, которые будут доступны Си-программе как int j, делайте это так (проверьте, что вы ассемблируете это в _DATA сегменте, если это необходимо):

Чтобы обращаться с Си-массивами необходимо знать размер элементов этого массива. Например, int переменные имеют размер 4 байта, поэтому если в Си-программе объявлен массив как int a[10], можно обращаться к a[3] так: mov ax,[_a+12]. ( Смещение 12 полчается в результате умножения номера в массиве, 3 на размер элемента массива, 4.) Размеры базовых типов в 32-х разрядных Си-компиляторах: 1 для char, 2 для short, 4 для int, long и float, и 8 для double. Указатель, содержащий 32-ух битный адрес имеет также размер 4 байта.

Чтобы обращаться к структурам языка Си, необходимо знать смещение от базового адреса структуры до интересующего вас поля. Вы можете просто это делать, конвертируя определения Си-структур в определения структур NASM (STRUC), или вычисляя одно смещение и используя только его.

Чтобы делать это проще, вам необходимо причитать руководство по вашему компилятору языка Си и найти как он организует структуры данных. NASM не делает специальных выравниваний членов структуры в его макросе STRUC, поэтому вы должны указывать выравнивания самостоятельно, если Си-компилятор генерирует их. Обычно вы можете обнаружить, что подобная структура

имеет размер не 5 байт, а 8, так как int поле будет выровнено на границу двойного слова. Однако, эту возможность иногда можно настроить в Си-компиляторе, используя параметры командной строки или #pragma - директивы, поэтому можно найти как ваш компилятор это делает.

8.1.4 c32.mac: Вспомогательные макросы для 32-ух битного интерфейса с Си

Файл макроса c32.mac включен в архив NASM, в каталог misc. В этом файле определены 3 макроса: proc, arg и endproc. Они введены для использования в определении процедур в стиле Си, и она автоматизируют операции, необходимые для соблюдения конвенции вызова.

Пример ассемблерной функции, использующей этот набор макросов приведен ниже:

Этот фрагмент определяет _proc32 как процедуру с двумя аргументами, первый (i) является integer и второй (j) является указателем на integer. Процедура возвращяет i + *j.

Заметьте, что макрос arg при его разворачивании содержит в первой строке EQU, которая в результате определяет %$i как смещение от BP. При этом используются контекстно-локальные переменные (локальные к контексту, сохраняемому в контекстном стеке макросом proc и удаляемому оттуда макросом endproc), поэтому в других процедурах может быть использовано то же самое имя аргумента. Конечно, вы можете этого не делать.

arg можно передать необязательный параметр, указывающий размер аргумента. Если размер не задан, он предполагается равным 4-ем, потому что абсолютное большинство параметров функции будут типа int или указателями.

8.2.1 Получение адреса ГТС

Каждый фрагмент кода в вашей разделяемой библиотеке должен определить ГТС как внешнее имя:

В начале каждой функции вашей разделяемой библиотеки, которая собирается обращаться к вашим секциям data или BSS, должен вычисляться адрес ГТС. Это обычно осуществляется написанием функции в такой форме:

(Для BSD, снова, имя _GLOBAL_OFFSET_TABLE нужно предварить вторым знаком подчеркивания.)

Первые две сточки этой функции - это просто стандартное начало для Си, чтобы установить стековый кадр, и последние три строчки - стандартное завершение Си-функции. Третья строка, и с четвертой по последнюю сктроки, сохраняют и восстанавливают регистр EBX, потому что PIC (перемещаемый код) разделяемая библиотека использует этот регистр для сохранения адреса ГТС.

Интересный фрагмент это инструкция CALL и следующие за ней две строки. Комбинация CALL и POP получают адрес метки .get_GOT, без узнавания в точности куда загружена программа (потому что инструкция CALL кодируется относительно текущей позиции). Инструкция ADD позволяет использовать специальный PIC (перемещаемый код) тип размещения: GOTPC размещение. Со спецификатором WRT ..gotpc размещение имен (здесь _GLOBAL_OFFSET_TABLE_, специальное имя, связанное с ГТС) дается как смещение от начала секции. (Вобще-то, ELF кодирует это как смещение от поля операндов инстуркции ADD, но NASM нарочно это упрощает, поэтому этот метод подходит для обоих ELF и BSD.) Таким образом, затем инструкция добавляет начало секции, чтобы получить настоящий адрес ГТС, и вычитает значение .get_GOT которое находится в EBX. Поэтому, в то время, когда инструкция завершится, EBX содержит адрес ГТС.

Если вы не следили за рассуждениями, не беспокойтесь: никогда не приходится получать адрес ГТС другими способами, поэтому вы можете поместить эти три инструкции в макрос и не обращать на них внимания:

8.2.2 Нахождение ваших локальных переменных

Имея ГТС, вы можете использовать ее для получения адресов ваших переменных. Большинство переменных будут постоянно находится в секциях, которые вы объявили; к ним можно получить доступ, используя ..gotoff специальный тип WRT. Вот как это работает:

Выражение myvar wrt ..gotoff вычисляется, затем разделяемая библиотека линкуется, чтобы оно стало смещением локальной переменной myvar от начала ГТС Поэтому, прибавление его к EBX, как это показано выше, помещает настоящий адрес myvar в EAX.

Если объявить переменные как GLOBAL без указания их размера, они разделяются между фрагментами кода в библиотеке, но не могут быть экспортированы из библиотеки в программу, которая ее загрузила. Они будут по прежнему в вашей обычных секциях data и BSS, поэтому доступ к ним можно получить таким же методом, что и к локальным переменных, используя описанный ранее механизм ..gotoff.

Обратите внимание, что из-за специфики в BSD a.out формата описатели этого перемещаемого типа, должно существовать хотя бы одно нелокальное имя в той же секции, что и адрес, к которому вы обращаетесь.

8.2.3 Нахождение внешних и общих переменных

Если вашей библиотеки требуется получить внешнюю переменную (внешнюю по отношению к library, не только к одному модулю в ней), необходимо использовать тип ..got, чтобы этого добиться. Тип ..got, вместо того, чтобы давать смещение от базы ГТС до переменной, дает смещение от базы ГТС до элемента ГТС, содержащего адрес переменной. Линковщик настраивает этот элемент ГТС когда делает библиотеку, и динамический линковщик помещает правильный адрес во время загрузки. Таким образом, чтобы получить адрес внешней переменной extvar в EAX, вам понадобиться написать:

Эта строчка загружает адрес extvar из элемента ГТС. Линковщик, когда он делает разделяемую библиотеку, собирает вместе все перемещения типа ..got, и создает ГТС, поэтому это обеспечивает существование каждого необходимого элемента.

Общие переменные должны использоваться таким же образом.

8.2.4 Экспортирование имен в библиотеку пользователя

Чтобы экспортировать имена пользователю библиотеки, необходимо объявить являются ли они функциями или данными, и если это данные, необходимо указать размер переменной. Это нужно для того, чтобы динамический линковщик создает таблицу связей входов процедур для каждой экспортированной функции, а также перемещает экспортированные переменные из секции данных библиотеки в которой они были объявлены.

Таким образом, чтобы экспортировать функцию в библиотеку пользователя, необходимо использовать

А чтобы экспортировать переменные, такие как массивы, понадобится такой код

Будьте осторожны: если экспортировать переменную в библиотеку пользователя, объявив ее как GLOBAL и указать ее размер, переменная окажется в сегменте данных главной программы, вместо сегмента данных вашей библиотеки, в котором объявлена. Поэтому получать доступ к вашей глобальной переменной вам нужно, используя механизм ..got, вместо ..gotoff, как если бы она была внешней (которая, вобщем, таковой и стала).

В равной мере, если необходимо сохранить адрес экспортированной глобальной переменной в вашем сегменте данных, вам ен удастся это сделать стандартным образом:

NASM интерпретирует этот код как обычное резервирование, в котором global_data_item просто смещение от начала сегмента .data (или чего-то другого); поэтому это определение будет указывать на ваш сегмент данных, вместо экспортирования глобальной переменной, которая находится в другом месте.

Вместо вышеописанного кода, тогда, используйте

что использует специальный тип WRT ..sym, чтобы указать NASM-у искать в таблице имен особое имя для этого объявления, место простого определения относительно базы сегмента.

Тотже метод будет работать и для функций: объявление одной из ваших функций следующим образом

предоставит пользователю адрес вашего кода, тогда как

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

8.2.5 Вызов процедур вне библиотеки

Вызов процедур извне вашей разделяемой библиотеки может быть осуществлен через таблицу сборки процедуры(procedure linkage table), или ТСП(PLT). ТСП помещается по известному смещению от того места, куда загружена библиотека, поэтому библиотечный код может делать вызовы к ТСП в переносимом (не зависимого от места) стиле. Внутри ТСП есть код для перехода на смещения, расположенные в ГТС, поэтому вызовы из функции к другим разделяемым библиотекам или к коду в главной программе могут быть незаметно направлены на их реальные местоположения.

Чтобы вызывать внешний код, необходимо использовать другой специальный PIC (переносимый код) тип переноса, WRT ..plt. Это намного проще, чем использовать ГТС: просто замещается вызовы, например, такие CALL printf на версию, использующую ТСП - CALL printf WRT ..plt.

8.2.6 Создание библиотечного файла

Написав несколько модулей с кодом и ассемблировав их в .o файлы, вы создаете вашу разделяемую библиотеку командами наподобие таких:

Для ELF, если вашу разделяемую библиотеку предполагается использовать в системных каталогах, таких как /usr/lib или /lib, это обычно делают, использую параметр -soname при сборке (линковке), чтобы сохранить конечный библиотечный файл с именем, с номером версии в библиотеке:

А вы потом скопируете файл library.so.1.2 в библиотечный каталог, и создадите символьную ссылку library.so.1 к нему.

10.1.1 Генерация NASM неэффективного кода

Я получаю много сообщений об ошибках, в которых говорится, что NASM генерирует неэффективный или неверный (при использовании инструкций типа ADD ESP, 8) код. Это преднамеренная особенность дизайна, связанная с предсказуемостью вывода: видя инструкцию типа "ADD ESP, 8", NASM генерирует команду, оставляющую место для 32-битного смещения. Если вы хотите использовать оптимизированную по размеру инструкцию, то должны использовать "ADD ESP, BYTE 8". Это не ошибка, это просто моя точка зрения.

10.1.2 Мои "JUMPы" вне диапазона

Также люди жалуются, что когда они используют переходы по условию (которые являются типа SHORT по умолчанию), которые пытаются перейти слишком далеко, то NASM сообщает "SHORT JUMP OUT OF RANGE", вместо использования более длинного перехода.

Это снова частичная проблема предсказуемости, имеющая также практическую причину. NASM не имеет возможности узнать, для какого типа процессора будет использоваться этот код, так что он не может решить сам использовать переход типа NEAR, потому что не знает, что программа предназначается для процессора 386 и выше. Аналогично, NASM может заменить инструкцию JNE типа SHORT, которая пыталась бы выйти за диапазон, на более короткую команду JE, использующей JUMP NEAR - это разумное решение для процессоров ниже 386, но не эффективное для процессоров, имеющих хорошее предсказание перехода и в состоянии осуществить JMP NEAR. Так что, повторяю - это пользователю, а не ассемблеру решать, какие команды должны быть сгенерированы.

Люди, пишущие загрузочный сектор в двоичном формате, часто жалуются, что ORG работает не так, как им хотелось бы: чтобы поместить сигнатуру 0xAA55 в конец 512-ти байтного загрузочного сектора, те, кто привык к MASM, имеют тенденцию делать следующее

В NASM ORG не предназначена для этого. Правильный способ заключается в использовании директивы TIMES:

Директива TIMES вставит необходимое количество нулей в код вплоть до 510-го байта. Еще одно преимущество этого метода в том, что если вы выйдете за допустимые размеры загрузочного сектора, то NASM перехватит эту ошибку еще во время ассемблирования и сообщит об этом, так что вам не придется "доводить" программу дизассемблированием и поиском ошибки.

10.1.4 TIMES не работает

Другая обычная проблема с вышеупомянутым кодом бывает у тех, кто пишет

полагая, что $ - это просто число (как и 510), и что разница тоже будет числом и эту разницу можно спокойно преподнести TIMES.

NASM - модульный ассемблер: различные составляющие части разработаны так, чтобы их было легко повторно использовать по отдельности, так что они не обмениваются информацией без необходимости. В последствии, даже зная, что выходной двоичный формат имеет ORG 0 (и секция .text будет начинаться с 0), эта информация не поступит назад к оценщику выражений. Так что, с точки зрения оценщика, $ - не просто число, а адрес, включающий смещение от базы (основы) сегмента. Поэтому разница между $ и 510 тоже будет включать значение смещения от базы сегмента (0х1234:0х5678 вместо 0х5678, например). Значение, включающее смещение, нельзя передавать в качестве параметра директиве TIMES.

Решение можно увидеть в предыдущем примере:

Здесь $ и $$ содержат смещения относительно одного и того же сегмента, так что их разница - простое число. Это решит проблему и будет сгенерирован правильный код.