3. Надати інформацію про реалізацію функцій api на рівні ос та на рівні системи програмування.

Реалізація функції АРІ на рівні ОС. При реалізації функцій АРІ на рівні ОС за їх виконання Відповідальність Несе ос. Об'єктній код, виконуючи функції, або безпосередню входити в склад ОС, або постачається в складі дінамічно завантажуючі бібліотек, розроблення для даної ОС. Система програмування, відповідальна Тільки за ті, щоб організуваті інтерфейс для виклик цього коду. Недоліком організації АРІ по такій схемі являється практично Повна відсутність перенесення не Тільки коду результуючої Програми, але и коду віхідної програм. Програма, створи для одної архітектури враховуючої системи, не зможите віконуваті на враховуючій систем іншої архітектури навіть після того, Як її об'єктній код буде повністю перебудованій. Скоріше Всього систем програмування НЕ зможите віконаті перебудову віхідного коду для Нової архітектури враховуючої системи, оскількі Багато функцій АРІ орієнтовані на візначені ОС будуть у новій архітектурі просто відсутні. Реалізація функції АРІ на рівні системи програмування. Якщо функції АРІ реалізуються на рівні системи програмування то смороду представляються користувач у вігляді бібліотекі функцій відповідної мови програмування. RTL (rub time library). Система програмування представляє користувань бібліотеку відповідної мови програмування в забезпечує підключення до результуючої Програми об'єктного коду, відповідального за виконання усіх функцій. Очевидно, Що Ефективність функцій АРІ в такому варіанті буде Трохи ніжча Ніж при безпосередню звертанні до функцій ОС. Існування всіх необхідніх вікліків и звертань до функції ОС у об'єктному коді RTL забезпечує система програмування. Однак перенесення віхідного коду Програми у такому варіанті буде найвищу, оскількі Синтакс и семантика всіх функцій Будуть суворі регламентовані у стандарті відповідного язика програмування. Смороду залежатися від мови І не залежатися від архітектури цільової враховуючої системи. Тому для виконання прікладної Програми на новій архітектурі враховуючої системи Досить заново побудуваті код результуючої Програми за допомога відповідної системи програмування. Одноманітні виконання функції мови, забезпечується системою програмування. При орієнтації на Різні архітектури цільової враховуючої системи в сістемі програмування можут буті Потрібні Різні комбінації вікліків функції ОС для виконання одних и тих функцій віхідної мови. Це винне буті враховано в коді RTL. У загально випадка для кожної архітектури цільової враховуючої системи буде потрібен Свій код RTL мови програмування. Вибір того чи іншого об'єктного коду RTL для підключення до результуючої Програми система програмування забезпечує автоматично.

Білет 16

1. Надати інформацію про основні системні таблиці вводу/виводу.

Системні таблиці вводу-виводу Організація вводу-виводу вимагає наявності інформації про ресурси (пристроях) і їх стан. Ця інформація зазвичай зберігається в системних таблицях, основними з яких є: - Таблиця обладнання (ET - eguipment table, список УВВ, підключених до системи); - Таблиця віртуальних логічних пристроїв (DRT - device reference table); - Таблиця переривань (IT - interrupt table). Окремий елемент першої таблиці називається блоком управління відповідним пристроєм обміну (UCB - unit control block) і містить наступну інформацію про пристрій: - Тип, модель, ім'я та характеристики пристрою; - Характеристики підключення (тип інтерфейсу, порт, лінія запиту переривання); - Вказівка ​​на драйвер управління та адреси його секцій; - Наявність та адресу буфера обміну для пристрою; - Уставка тайм-ауту та адресу клітинки зберігання лічильника тайм-ауту; - Стан пристрою; - Дескриптор задачі, що використовує пристрій в даний момент часу і т.п. Друга таблиця DRT позбавляє програміста від необхідності знання конкретних параметрів пристрою. Звертаючись до логічного імені пристрою, програміст за допомогою таблиці опису віртуальних логічних пристроїв встановлює зв'язок з певним пристроєм. Т.ч., ця таблиця перенаправляє запит вводу-виводу на ті модулі і структури даних, які зберігаються у відповідному елементі першої таблиці. Третя таблиця IT для кожного запиту на переривання вказує UCB, співставлений цим запитом.

Запит на ввід-вивід від виконується програми надходить на супервізор програм (дія 1). Він перевіряє виклик на відповідність прийнятим специфікаціям. У разі коректності запиту він перенаправляється в супервізор введення-виведення (крок 2), інакше завданню повертається відповідне повідомлення (дія 1-1). Супервізор введення-виведення по логічному (віртуальному) імені таблиці DRT знаходить відповідний елемент UCB в таблиці обладнання. Якщо пристрій зайнятий, то описувач завдання поміщається в чергу до пристрою, інакше запускається препроцесор вводу-виводу. Він формує послідовність керованих кодів і даних для пристрою введення-виведення. Коли послідовність сформована, супервізор введення-виведення передає управління відповідного драйверу в секції запуску (дія 3). Драйвер ініціює операцію управління, обнуляє лічильник тайм-ауту і повертає управління диспетчеру задач для постановки завдання на процесор (дія 4). Після закінчення обробки команди введення-виведення пристрій вводу-виводу виставляє сигнал запиту переривання, за яким управління передається секції продовження (дія 5). Отримавши нову команду, УВВ знову її обробляє, а управління процесором знову передається диспетчеру завдань, і процесор продовжує обчислення. Таким чином реалізується паралельна обробка завдань, на тлі якої відбувається управління введенням-висновком.