Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Lekz._4.doc
Скачиваний:
2
Добавлен:
11.08.2019
Размер:
177.66 Кб
Скачать

Підготовка програми до перетворення і виконання.

На рис. 4.1 показаний тільки початковий код програми, не перетворюванної у виконуваний формат. Для введення цієї програми ми можемо використовувати будь-який текстовий редактор (напр. Norton або Блокнот), який може зберігати текст у вигляді простого ASCII-файлу без форматування. Запустіть програму текстового редактора, введіть речення програми, наведеної на рис. 4.1, і назвіть файл у відповідності з лістингом A04ASM1.ASM.

Хоча вирівнювання тексту не суттєво для асемблера, програма стане більш доступною для розуміння, якщо ми будемо записувати ім'я, операцію, операнд і коментарі в чітко вирівняній по стовпцях формі. Багато редакторів дозволяють використовувати табуляцію для створення стовпців шириною 8 символів.

Після введення всіх речень програми перевірте їх правильність. У тому вигляді, в якому вона є, програма є просто текстовим файлом, який не може прямо виконуватися - його необхідно спочатку відтранслювати і скомпонувати. На рис. 4.2 показані кроки, необхідні для компіляції, компонування і виконання програми.

1. Крок асемблювання включає в себе трансляцію машинного коду в об'єктний код і створення проміжного файлу (модуля) типу. OBJ (об'єктного). Одне із завдань асемблера - обчислення зміщень для кожного елемента даних у сегменті даних і для кожної інструкції в сегменті коду. Асемблер також створює заголовок, що розташовується на самому початку генерованого файлу типу .OBJ. Частина заголовка містить інформацію про неповні адреси. Файл типу .OBJ - ще не виконуваний модуль.

2. Крок компонування включає в себе перетворення об'єктного файлу у виконуваний (типу.ЕХЕ) файл в машинних кодах. Завдання компонувальника - формування повних значень будь-яких адрес, що асемблер залишив неповними, і складання роздільно асембльованих програм в єдиний модуль.

3. Останній крок - завантаження програми для виконання. Оскільки завантажувач знає, де програма повинна розташовуватися в пам'яті, він може вибрати відповідні значення для адрес, котрі все ще залишаються неповними в заголовку. Завантажувач відкидає заголовок і створює префікс сегмента програми безпосередньо перед завантаженням програми в пам'ять.

2. Асемблювання початкової програми

Асемблер перетворює початкові речення програми в об'єктний код і виводить на екран повідомлення про виявлені помилки. Типові помилки - це, наприклад, імена, які не відповідають угодам про допустимі в програмах на асемблері імена, неправильно написані імена інструкцій (наприклад, MOVE замість MOV) і операнди, що містять невизначені імена. Оскільки різновидів помилок досить багато (100 або більше) і у різних версій асемблерів вони відрізняються, то за повним списком (і описом) помилок потрібно звернутися до опису конкретної версії асемблера. Асемблер може спробувати виправити деякі помилки, але в будь-якому випадку краще знову завантажити початковий файл у редактор, виправити помилки і повторно відтранслювати програму.

Результатом роботи асемблера є файли типу .OBJ (об'єктні), .LST (листинги), .CRF (файл перехресних посилань). Зазвичай потрібен файл типу .OBJ, який можна скомпонувати у виконуваний модуль. Можуть також знадобитися лістинги (файли типу .LST), особливо якщо вони містять діагностичну інформацію про помилки або ми хочемо дослідити згенерований машинний код. Файли типу .CRF (або .SBR, або .XRF - залежно від версії асемблера) корисні у великих програмах, де ви маєте дізнатися, які інструкції звертаються до яких елементів даних. Крім того, вимога створити файл типу .CRF змушує асемблер згенерувати номери для елементів (інструкцій) файлу .LST, на які посилається файл .CRF.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]