Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

Збірка у момент завантаження

  ...як тільки вони увійшли до Безконечного Лісу, зібраний джентельмен почав розбиратися на частини і почав виплачувати орендні гроші. Спочатку він відправився до ногозаїмодавцам і прийшов туди, де найняв ліву ногу; він віддав її власникові, і заплатив за оренду, і застрибав до господаря правої ноги; коли він повернув її і повністю розплатився, то перекинувся вниз головою і пострибав на руках.
А. Тутуола

Як ми бачили в попередньому розділі, об'єктні модулі і бібліотеки містять досить інформації, щоб збирати програму не лише заздалегідь, але і безпосередньо у момент завантаження. Цей спосіб, безумовно, вимагає великих витрат процесорного часу, чим завантаження заздалегідь зібраної коди, але дає і деякі переваги.
Головна перевага полягає в тому, що, якщо ми завантажуємо декілька програм, що використовують одну і ту ж бібліотеку, ми можемо набудувати їх на роботу з однією копією коди бібліотеки, таким чином, заощадивши пам'ять. Розділення коди привабливе і з функціональної точки зору, тому збірка у момент завантаження знаходить широке вживання в найрізноманітніших ситуаціях.
Прикладом такої збірки є широко використовувана в Windows всіх версій і Os/2 технологія DLL (насправді, DLL забезпечують збірку не лише у момент завантаження, але і після неї — можливість підключити додатковий модуль до вже завантаженої програми), яка буде детальніша обговорюватися далі. Як інші приклади можна привести Novell Netware, Os-9, Vxworks і так далі Втім, якщо ми говоримо про системи, призначені для використання у вбудованих застосуваннях (тій же Vxworks), питання про те, чи є збірка перед прошивкою в ПЗП збіркою у момент завантаження або збіркою заздалегідь, носить схоластичний характер.
Деякі системи команд підтримують динамічно збирані заново програми, в яких все налаштування модуля винесене в окрему таблицю. В цьому випадку модуль може бути підключений одночасно до декількох програм, використовувати одночасно різні копії сегменту даних, і кожна використовувана копія модуля при цьому навіть не підозрюватиме про існування інших. Прикладом такої архітектури є Pascal-система Lilith, розроблена Н. Віртом, і її спадкоємці Kpohoc/n9000.

Програмні модулі в N9000
У цій архітектурі кожен об'єктний модуль відповідає одному модулю в сенсі мови високого рівня Oberon (або NIL— N9000 Instrumental Language). Далі ми описуватимемо архітектуру системи N9000, оскільки автор з нею краще знаком.
Модуль може мати не більше 256 процедур, не більше 256 змінних і посилатися не більше ніж на 256 інших модулів. Код модуля є не-залежним. Дані модуля зібрані в окремий сегмент, і для кожної використовуваної копії модуля, тобто для кожної програми, яка цей модуль використовує, створюється своя копія сегменту даних. На початку сегменту содер.
жітся таблиця змінних. Рядки цієї таблиці містять або значенія_
для скалярних змінних, таких як ціле число або покажчик, або адреси в сегменті даних. Крім того, сегмент даних містить заслання на сегмент коди. Цей сегмент коди містить в собі таблицю адрес точок входу всіх визначених в нім функцій (мал. 3.13).

Мал. 3.13. Модуль N9000

Заслання на всі зовнішні модулі зібрані в таблицю, яка також міститься в сегменті даних. Зовнішній модуль визначається початком його сегменту даних
Всі заслання на об'єкти в даному модулі здійснюються через індекс у відповідній таблиці. Заслання на зовнішні модулі мають вигляд індекс модуля:індекс об'єкту.
Сегмент даних не може містити жодних статично ініциалізованних даних. Вся ініціалізація проводиться спеціальною процедурою, яка викликається при кожному новому використанні модуля. Всі ці властивості реалізовані в системі команд, тому накладні витрати відносно невеликі.
Точніше, вони невеликі в порівнянні з Intel 80286, але вже завеликі в порівнянні з i386, а в порівнянні з сучасними RISC-процессорами або системами типа трансп'ютера вони стають неприпустимими. Втім, в разд. Бібліотеки, що розділяються ми побачимо, як подібна структура використовується і на "звичайних" процесорах.
Видно, що в системі може існувати декілька програм, що звертаються до одних і тих же модулів і використовують одну і ту ж копію коди модуля. Проблем з абсолютной/относительной завантаженням взагалі не виникає. Операційна система ТС для N9000 була (автор не упевнений, чи існує в даний час хоч би одна працездатна машина цієї архітектури) заснована на збірці програм у момент завантаження. У системі була спеціальна команда load — "завантажити всі модулі, використовувані програмою, і розмістити для них сегменти даних, але саму програму не запускати". У пам'яті могло знаходитися одночасно декілька програм; при цьому модулі, використовувані декількома з них, завантажувалися в одному екземплярі. Це значно прискорювало роботу. Наприклад, можна було завантажити в пам'ять текстовий редактор, і запуск його займав би долі секунди, замість десятків секунд, які потрібні для завантаження з жорсткого диска фірми ІЗОТ.
Цікаво, що коли почалася реалізація системи програмування на мові З для цієї машини, з ряду причин було вирішено не зв'язуватися з динамічною збіркою, а збирати звичайні переміщувані завантажувальні модулі.
На практиці, подібна архітектура характерніша для байт-кодов — пре-компілірованних представлень програми, призначених для подальшої обробки інтерпретатором, — Java Virtual Machine, інтерпретатором Smalltalk і т. д., чим для апаратний реалізованих систем команд. У таких системах команд деколи використовуються і екстравагантніші рішення.

Архітектура As/400
Система команд As/400 (сервер баз даних середнього рівня, вироблюваний IBM) є машинно-незалежним байтом-кодом. При завантаженні програми цей байт-код компілюється в бінарний код "реального" процесора, подібно до того, як це робиться в більшості сучасних реалізацій Java Virtual Machine. Точніше, навпаки, успіх As/400 був одним з важливих чинників, які подвіглі фірму Sun на розробку Java, тому правильніше говорити, що сучасні JVM засновані на тому ж принципі компіляції при завантаженні, що і As/400.
Це рішення забезпечує невисоку вартість апаратури (сучасні As/400 засновані на мікропроцесорах архітектури Power РС. Їх вища в порівнянні з машинами, заснованими на процесорах х86, ціна обумовлена продуктивнішими системною шиною і периферією), високу продуктивність і можливість замінювати архітектуру "реального" процесора без перекомпіляції призначеного для користувача програмного забезпечення. За час випуску машин цієї серії така заміна відбувалася двічі.
З іншого боку, відсутність необхідності вважати про те, як та або інша можливість може бути реалізована апаратний, дозволила приймати весиуа авангардистські рішення, на які не вирішувався ніхто з розробників апаратний реалізованих CISC-архитектур, таких як VAX, Eclipse і навіть апофеозу CISC, Intel 432.
As/400 має єдиний адресний простір в тому сенсі, що об'єктами, що адресуються, є не лише сегменти коди і скалярних даних, але і об'єкти реляційної СУБД, такі, як таблиці, індекси, курсори і так далі
Фактично, адресації підлягає вся пам'ять системи як оперативна, так і дискова. Адресу має дві вистави: його сегментна частина може зберігати ім'я об'єкту (у контексті цієї глави це можна уподібнити недозволеному зовнішньому засланню), що адресується, або власне адресу, 64-бітове бінарне значення. Перед тим, як звернутися до об'єкту, адресу-ім'я треба перетворити в бінарний формат, для чого існують спеціальні команди [redbooks.ibm.com sg242222.pdf].
Механізм цього перетворення виконує роботу і файлової системи, і редактора зв'язків, в тому сенсі, що і файловий доступ, і збірка програми містять важливу фазу перетворення імен (відповідно, імен файлів і імен зовнішніх символів) в адреси, по яких можна здійснювати доступ.

Збірка при завантаженні уповільнює процес завантаження програми (втім, для сучасних процесорів це уповільнення навряд чи має велике значення), але спрощує, з одного боку, розділення коди, а з іншого боку — розробку програм. Дійсно, з класичного циклу внесення зміни в програму: редагування тексту — перекомпіляція — пересборка — перезавантаження (програми, не обов'язково всієї системи) випадає ціла фаза. В разі великої програми це може бути тривала фаза. В разі Novell Netware вирішальною виявляється перша перевага (мал. 3.14), в разі систем реального часу однаково важливі обидва.
У більшості сучасних ОС, насправді, збірка у момент завантаження походить не з об'єктних модулів, а із заздалегідь зібраних бібліотек, що розділяються. Такі бібліотеки відрізняються від тих, що обговорювалися в разд. Об'єктні бібліотеки по-перше, тим, що з них неможливо витягувати окремий модуль: всі міжмодульні заслання усередині такої бібліотеки дозволені, і її необхідно завжди завантажувати як ціле; і, по-друге, тим, що список символів, що експортуються такою бібліотекою, не є об'єднанням списків експорту складових її об'єктних модулів. При збірці такої бібліотеки необхідно вказати, які з символів експортуватимуться. Деякі редактори зв'язків дозволяють на цьому етапі створювати додаткові символи.

Мал. 3.14. Фрагмент структури взаїмозавісимостей між NLM (Netware Loadable Module) сервера Netware 4.11

 

:: Реклама ::

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017