Правила оформления программ на ассемблере

Практическое овладение навыками упрощённого оформления простейших программ на языке Ассемблера и работы с программами TASM и TLINK.

2 Теоретический материал
2.1 Упрощенное оформление программ

Для создания простых программ, которые содержат по одному сегменту для данных и кода, а также для программ, модули которых предполагается связывать с программами на языках высокого уровня, используются упрощенные директивы сегментации. При этом структура исходного модуля несколько упрощается.

Такие программы начинаются с директивы указания модели памяти .MODEL, которая в простейшем случае имеет формат:

.MODEL [, язык)

Здесь — — имя выбранной модели памяти, является обязательным операндом;

— [язык] — имя языка программирования, на котором написаны вызываемые из данного модуля процедуры. Это может быть С, Pascal, Basic и другие.

Если программа написана полностью на Ассемблере, то достаточно указать только модель памяти. Возможные модели памяти и их описание приведены в таблице 2.1. Как видно из этой таблицы выбор директивы .MODEL определяет набор сегментов программы, размеры сегментов данных и кода, способы связывания сегментов и сегментных регистров. Директиву ASSUME, в отличие от способа традиционного оформления сегментов, не используют.

ВИРУС на Ассемблере | Как программно отключить монитор?

Для программ на Ассемблере используется модель памяти Small.

Применение директивы .MODEL обязывает программиста использовать для описания сегментов исходного модуля упрощенные директивы описания сегментов. Каждая из моделей может использовать директивы, представленные в таблице 2.2.

CS = DS = SS = dgroup Код и данные объединены в одну группу с именем dgroup.

Для создания *.com программ

Код занимает один сегмент. Данные объединены в одну группу с именем dgroup.

Для небольших и средних программ (*.ехе). Для программ на Ассемблере.

CS = _text Несколько сегментов кода. Данные объединены в одну группу с именем dgroup.

Для больших программ с малым объемом данных.

Код в одном сегменте. Данные объединены в одну группу с именем dgroup.

Сегмент кода 64К. Объем данных не ограничен.

CS = _text Код в нескольких сегментах. Данные объединены в одну группу с именем dgroup.

Размер кода и данных не ограничены. Для больших программ.

Тоже, что и large. Для совместимости с

Используется при программировании на Turbo С и Borland C++.

Используется в среде OS/2.

Упрощенные директивы описания сегментов_______

Сегмента инициализированных данных

Сегмента постоянных данных

Сегмента неинициализированных данных

.stack размер

Сегмента стека. Параметр задает размер стека

.fardata [илля]

Сегмента инициализированных данных типа far

Сегмента неинициализированных данных типа far

Для упрощения ссылок к именам сегментов введены несколько предопределенных идентификаторов, которые могут использоваться в программе. Основные из них представлены в таблице 2.3.

#1 Первая программа на ассемблере MASM

Идентификаторы, создаваемые директивой MODEL

Значение: Физический адрес сегмента

Данных типа near

Неинициализированных данных типа near

Данных типа far

Неинициализированных данных типа far

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

;Forma_l — упрощенное оформление программ

.MODEL SMALL ; модель памяти ближнего типа

.STACK 100h ; определить стек размером 100h

.DATA ; открыть сегмент данных

В этом сегменте определяются данные с использованием символических имен

; открыть сегмент кодов

; сегментный регистр DS

Здесь следуют команды, которые определяются алгоритмом решаемой задачи

mov AL, О mov АН, 4Ch int 21h

; конец исходного модуля.

Как следует из описанного выше, исходный модуль содержит три сегмента с именами STACK, DATA и CODE, организованных с помощью упрощенных директив создания сегментов .STACK, .DATA и .CODE. После загрузки программы в память каждый из сегментных регистров будут указывать на начало соответствующего сегмента программы: регистр DS на сегмент данных, регистр SS на сегмент стека, регистр CS на сегмент кода. Расположение сегментов в памяти описывается с помощью образа программы, который приведен на рис. 2.1.

Образ программы *.ехе в памяти

Рис. 2.1 — Образ программы *.ехе в памяти

Как следует из рисунка, образ программы содержит три логических сегмента, которые присутствуют в исходном тексте. Длина каждого сегмента определяется их содержимым:

— для сегмента кодов — числом команд и их длиной;
— для сегмента данных — количеством и размером переменных, объявленных в программе;
— для сегмента стека — числом зарезервированных под стек ячеек памяти.

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

2.2 Создание исполняемых модулей типа *.сот

По внутренней организации все программы, написанные для MS DOS, принадлежат к одному из двух типов. Каждому из них соответствуют имена с расширениями *.ЕХЕ или *.СОМ. Программы, составленные в лабораторной работе № 1 с помощью стандартных директив сегментации, относятся к наиболее распространенному типу .EXE приложений.

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

Во многих случаях объем программы оказывается значительно меньше 64 Кбайт. Такую программу нет никакой необходимости составлять из нескольких сегментов. В этом случае и данные и стек и команды можно разместить в одном сегменте, настроив все сегментные регистры на его начало. Исполняемые файлы, составленные по этим правилам, имеют расширение *.СОМ, В виде .СОМ приложений обычно пишутся резидентные программы и драйверы, хотя в таком виде можно оформить любую прикладную программы.

Для написания исходных текстов программы типа .СОМ можно использовать приведенный ниже шаблон:

;Forma_2 — исходный модуль для создания *.сот приложения

Begin: jmp Start

; модель памяти ближнего типа

; открыть сегмент кодов

; отвести 256 байт под PSP

; безусловный переход на

Здесь определяются данные

с использованием символических имен

Здесь следуют команды, которые определяются алгоритмом решаемой задачи

mov AL, 0 ; завершить программу

mov АН, 4Ch ; с помощью

END Begin ; конец исходного модуля.

Из исходного текста видно, что программа использует упрощенные директивы сегментации и содержит один сегмент — сегмент кода. Оператор ORG 100h резервирует 256 байт в памяти для сегмента префикса программы (Program Segment Prefics — PSP). Этот сегмент содержит таблицы и поля данных, которые заполняются и используются системой в процессе выполнения программы.

Данные, необходимые программе, можно объявить перед командами, внутри них или в конце сегмента. Однако при загрузке программы типа .СОМ регистр счетчика команд IP всегда инициализируется числом 100h, поэтому вслед за оператором ORG 100h должна стоять первая выполняемая программой команда. В нашем случае это команда безусловного перехода на метку Start:

Begin: jmp Start;

После загрузки программы в память все сегментные регистры указывают на начало сегмента, в котором располагается программа, фактически на начало PSP. Регистр указателя стека SP автоматически загружается числом — начальной точкой входа в стек FFFEh. Таким образом, независимо от размера программы, под нее отводится 64 Кбайта адресного пространства.

Всю нижнюю часть занимает стек, размер которого заранее не определен, а зависит от работы программы. Образ программы в памяти показан на рис. 2.2.

Префикс программы (PSP) 256 байт

Команды и данные

Рис. 2.2 — Образ программы .СОМ в памяти

Из рисунка видно, что программа состоит из единственного сегмента, содержимое которого почти точно отражает содержимое исходного модуля. Отличие заключается в том, в исходном модуле отсутствует префикс программы (PSP), который появляется в памяти в процессе загрузки программы.

Процесс ассемблирования исходного модуля происходит как обычно, а при вызове компоновщика TLINK.EXE в командной строке следует задавать ключ /t, который заставляет формировать исполняемый файл типа *.СОМ:

2.3 Организация паузы до нажатия клавиши

Один из способов организации ожидания нажатия клавиши использует функцию BIOS которая обеспечивает ожидание ввода символа с клавиатуры без его отображения на экране. К функциям BIOS позволяет обратиться команда прерывания INT 16h с номером 0, который должен быть загружен в регистр АН.

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

MOV АН, 00h ; пауза до

INT 16h ; нажатия клавиши

3 Подготовка к работе
3.1. Изучить методические указания и рекомендованную литературу.
3.2. Подготовить ответы на контрольные вопросы.
4 Задание на выполнение работы
4.1 Используя текстовый редактор, создать и отредактировать исходный модуль программы hello_2.asm, (см. лаб. раб. №1) с использованием директив упрощенного оформления программ. Сохранить исходный текст на диске с именем hello_2s.asm. При наборе исходного текста используйте шаблон Forma_l, описанный в п.2.1.
4.2 Используя компилятор Турбо Ассемблера tasm.exe создать файлы hello_2s.obj и hello_2s.lst.
4.3 Используя компоновщик tlink.exe создать файлы hello_2s.exe и hello_2s.map,
4.4 Убедиться в работоспособности программы hello_2s.
4.5 Добавьте в исходный текст программы hello_2s команды, которые вводят паузы до нажатия любой клавиши после вывода очередного сообщения на экран.
4.6 Просмотреть в текстовом редакторе тексты всех созданных файлов и проанализировать их. Уточнить размеры сегментов и нарисовать образ программы hello_2s.exe в памяти ЭВМ.
4.7 Используя текстовый редактор, создать и отредактировать исходный модуль предыдущей программы для создания исполняемого файла типа *.сош. Сохранить исходный текст на диске с именем hello_2c.asm. При наборе исходного текста используйте шаблон Forma_2, приведенный в п. 2.2.
4.8 Выполнить ассемблирование и компоновку созданного исходного модуля для создания исполняемого файла типа *.сот.
4.9 Убедиться в работоспособность созданного исполняемого файла.
4.10 Просмотреть в редакторе все созданные файлы и проанализировать их. Уточнить размеры сегментов и нарисовать образ программы hello_2c.com в памяти ЭВМ.
5 Требования к отчёту

Составление и оформление программ на ассемблере

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

Каждый логический (программный) сегмент должен начинаться с директивы SEGMENT (сегмент) и заканчиваться директивой ENDS (конец сегмента):

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

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

Необходимая ассемблеру информация о содержимом сегментных регистров сообщается в директиве ASSUME, имеющей следующий формат:

Поле SR содержит имя одного из сегментных регистров (CS, DS, SS, ES), а базовое значение указывает начало области памяти, адресуемой через сегментный регистр.

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

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

Правила оформления программ на ассемблере

Хотелось бы узнать ка наиболее правильно оформлять программы на ассемблере!
Как разделять блоки, макросы, выделять циклы и т.д.
Вот как пока оформляю я:

;————————
;Инициализируем порты
;Все порты- выходы, = 0
; CBI-0 SBI-1
SBI DDRB, DataPin ;
CBI PORTB, DataPin ;

SBI DDRB, ClockPin ;
CBI PORTB, ClockPin ;

Последний раз редактировалось Levsha100; 06.01.2010 в 23:06 .
Android Developer
Старожил Подтвердите свой е-майл
Регистрация: 19.02.2007
Сообщений: 3,708
По блочно с изобилием комментариев. Иначе — Смерть через пару дней
Заблокирован
Регистрация: 20.07.2008
Сообщений: 4,033
Хотелось бы поконкретней.
Какие комментарии Вы используете?

Ставите ли после каждой команды «;» (как в ЯВУ)?
Как оформляете блоки, комментарии.
Может есть системы типа Doxywizard для асма?

//А вообще хотелось бы создать цикл тем «Кодируем стильно», где показывается как правильно оформлять код, называть переменные и т.д.

Последний раз редактировалось Levsha100; 07.01.2010 в 00:05 .
somewhere else
Участник клуба
Регистрация: 17.07.2008
Сообщений: 1,409

Такие комментарии есть только в GASM и еще каком то ассемблере, кажется YASM-е.

Если нужно что то прокомментировать делаю так:
;;################
;;## Hello world block ##
;;################

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

fdd_stop: mov dx,3F2h mov al,0 out dx,al nmi_disable: in al,70h or al,80h out 70h,al

Эти две метки совершенно не нужны, но с другой стороны они не так выделяются среди общей массы кода и в тоже время в ней не теряются.

«Тяжело в учении, легко в бою» — А.В. Суворов
Последний раз редактировалось Ivan_32; 07.01.2010 в 01:01 .
Android Developer
Старожил Подтвердите свой е-майл
Регистрация: 19.02.2007
Сообщений: 3,708
Пример блока

. xor eax,eax mov eax,1 ; Something is here and very important to udnerstand it xor eax,eax ; clear eax mov eax,1 ; move 1 to eax ; Next block xor eax,eax mov eax,1

А вообще понимаете, то как «правильно» будет для каждого свое. Я для себя выработал основные пунктики:
1. Использовать только English в наименовании функций, переменных и т.д.
2. Использовать (не сильно сокращать) имена функций, чтобы попытаться вложить весь смысл функции в ее имя, а так же параметры — их именовать так же, например FileName или Path или scan0 и т.п. т.е. сразу можно понять что есть параметр и для чего он нужен, на крайний случай сделать так

/* Make something with your PC drive — setup drive of the PC to be formated */ bool DriveFormat(char *drive)

т.е. именно DriveFormat, а не FormatDrive. Почему ? Т.к. в теории можно будет сгруппировать осмысленный набор функций например:
DriveFormat
DriveRemove
DriveMount
DriveUnmount и т.п.
А теперь представьте, чтобы было если бы Drive стоял в каждой функции на втором месте

Ну и так далее много мелочей. В принципе именно учится «правильно» писать, думаю никто не учит. Все приходит на практике, т.е. сама задача и ее решение ведут вас к тому идеалу «правильности» написания кода. В конце концов вам приходится видеть другие коды, их реализации и их структуру и вы автоматически добавляете новые, удобные и корректные способы написания кода, в результате постоянно формируете свой идеал

Думаю открывать еще тему для этого излишество.

Источник: www.programmersforum.ru

Составление и оформление программ на ассемблере

Правила оформления программ на ассемблере

Составьте блок схему и программу вычисления значения функции вариант 3

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

Как записать музыку на сд диск в формате сд программа

Какая нужна программа на телефон чтобы скачивать музыку на телефон

Если не хватает места на диске с для установки программы

Задачи по ознакомлению с формой и геометрическими фигурами в программе радуга

Как расширение имени файла связано с форматом файла и программой обработки

Что программа 12111 переводит число 50 в число 20 определите значение b