Типы меток
Хотя в программах Турбо Ассемблера можно свободно обращаться к любой переменной или данным любого размера (8, 16, 32 бита и т.д.), в общем случае хорошо обращаться к переменным в соответствии с их размером. Например, если вы записываете слово в байтовую переменную, то обычно это приводит к проблемам:
.
.
.
SmallCount DB 0
.
.
.
mov WORD PTR [SmallCount],0ffffh
.
.
.
Поэтому важно, чтобы в операторе Ассемблера EXTRN, в котором описываются переменные С++, задавался правильный размер этих переменных, так как при генерации размера доступа к переменной С++ Турбо Ассемблер основывается именно на этих описаниях.
Если в программе на языке С++ содержится оператор:
char c
то код Ассемблера:
.
.
.
EXTRN c:WORD
.
.
.
inc [c]
.
.
.
может привести к весьма неприятным ошибкам, поскольку после того, как в коде на языке С++ переменная c увеличится очередные 256 раз, ее значение будет сброшено, а так как она описана, как переменная размером в слово, то байт по адресу OFFSET c + 1 будет увеличиваться некорректно, что приведет к непредсказуемым результатам.
Между типами данных С++ а Ассемблера существует следующее соотношение:
| Тип данных С++ | Тип данных Ассемблера |
|---|
| unsigned char | byte | | char | byte | | enum | word | | unsigned short | word | | short | word | | unsigned int | word | | int | word | | unsigned long | dword | | long | dword | | float | dword | | double | qword | | long double | tbyte | | near* | word | | far* | dword |
Внешние дальние идентификаторы
Если вы используете упрощенные директивы определения сегментов, то описания идентификаторов EXTRN в сегментах дальнего типа не должны размещаться ни в каком сегменте, так как Турбо Ассемблер рассматривает идентификаторы, описанные в данном сегменте, как связанные с данным сегментом. Это имеет свои недостатки: Турбо Ассемблер не может проверить возможность адресации к идентификатору, описанному, как внешний (EXTRN), вне любого сегмента и поэтому не может в случае необходимости сгенерировать определение сегмента или сообщить вам, что была попытка обратиться к данной переменной, когда сегмент не был загружен корректным значением. Тем не менее Турбо Ассемблер генерирует для ссылок на такие внешние идентификаторы правильный код, но не может обеспечить обычную степень проверки возможности адресации к сегменту.
Если вы все-таки захотите, то можно использовать для явного описания каждого внешнего идентификатора сегмента старые директивы определения сегментов, а затем поместить директиву EXTRN для этого идентификатора внутрь описания сегмента. Это довольно утомительно, поэтому если вы не хотите обеспечивать загрузку корректного значения сегмента при обращении к данным, то проще всего просто разместить описания EXTRN для идентификаторов дальнего типа вне всех сегментов. Предположим, например, что файл FILE1.ASM содержит следующее:
.
.
.
.FARDATA
FileVariable DB 0
.
.
.
и он компонуется с файлом FILE2.ASM, который содержит:
.
.
.
.DATA
EXTRN FileVariable:BYTE
.CODE
Start PROC
mov ax,SEG FileVariable
mov ds,ax
.
.
.
SEG FileVariable не будет возвращать корректного значения сегмента. Директива EXTRN размещена в области действия директивы файла FILE2.ASM DATA, поэтому Турбо Ассемблер считает, что переменная FileVariable должна находиться в ближнем сегменте DATA файла FILE2.ASM, а не в дальнем сегмента DATA.
В следующем коде FILE2.ASM SEG FileVariable будет возвращать корректное значение сегмента:
.
.
.
.DATA
@CurSeg ENDS
EXTRN FileVariable:BYTE
.CODE
Start PROC
mov ax,SEG FileVariable
mov ds,ax
.
.
.
"Фокус" здесь состоит в том, что директива @CurSeg ENDS завершает сегмент .DATA, поэтому, когда переменная FileVariable описывается, как внешняя, никакая сегментная директива не действует.
Командная строка компоновщика
Простейший способ скомпоновать модули Borland C++ с модулями Турбо Ассемблера состоит в том, чтобы ввести одну командную строку Borland C++, после чего он выполнит всю остальную работу. При задании нужной командной строки Borland C++ выполнит компиляцию исходного кода Си, вызовет Турбо Ассемблер для ассемблирования, а затем вызовет утилиту TLINK для компоновки объектных файлов в выполняемый файл. Предположим, например, что у вас есть программа, состоящая из файлов на языке Си MAIN.CPP и STAT.CPP и файлов Ассемблера SUMM.ASM и DISPLAY.ASM. Командная строка:
bcc main.cpp stat.cpp summ.asm display.asm
выполняет компиляцию файлов MAIN.CPP и STAT.CPP, ассемблирование файлов SUMM.ASM и DISPLAY.ASM и компоновку всех четырех объектных файлов, а также кода инициализации С++ и необходимых библиотечных функций в выполняемый файл MAIN.EXE. При вводе имен файлов Ассемблера нужно только помнить о расширениях .ASM.
Если вы используете утилиту TLINK в автономном режиме, то генерируемые Турбо Ассемблером объектные файлы представляют собой стандартные объектные модули и обрабатываются также, как объектные модули С++. Описание TLINK в автономном режиме см. в Приложении С.
Взаимодействие между Турбо Ассемблером и Borland C++
Теперь, когда вы понимаете, как нужно строить и компоновать совместимые с С++ модули Ассемблера, нужно знать, какой код можно помещать в функции Ассемблера, вызываемые из С++. Здесь нужно проанализировать три момента: получение передаваемых параметров, использование регистров и возврат значений в вызывающую программу.
1 2 3 4 5 6 7 8 9
8 8 8
| |
*
Обратная связь