Питання до лекції
Яке завдання мікро архітектурного рівня ?
2. Що таке тракт даних?
3. Поясніть рисунок 7.1.
4. Як відбувається синхронізація тракту даних.
5. Яким чином працює пам’ять?
6. Роз’ясніть управління мікрокомандами в Міс-1.
7. Охарактеризуйте модель пам’яті IJVM.
8. Рівень архітектури команд
У цьому розділі детально обговорюється рівень архітектури команд. Він розташований між мікроархітектурним рівнем і рівнем операційної системи, як показано на мал. 8.1. Історично цей рівень розвинувся перш за всіх решти рівнів і спочатку був єдиним. В наші дні цей рівень дуже часто називають «архітектурою» машини, а іноді (що неправильне) «мовою асемблера».
Рівень архітектури команд має особливе значення: він є зв'язуючою ланкою між програмним і апаратним забезпеченням. Звичайно, можна б було зробити так, щоб апаратне забезпечення відразу безпосередньо виконувало програми, написані на C, С++, FORTRAN 90 або інших мовах високого рівня, але це не дуже хороша ідея. Перевага компіляції перед інтерпретацією була б тоді втрачена. Крім того, з чисто практичних міркувань комп'ютери повинні уміти виконувати програми, написані на різних мовах, а не тільки на одній.
По суті, всі розробники вважають, що потрібно транслювати програми, написані на різних мовах високого рівня, в загальну проміжну форму — на рівень архітектури команд — і відповідно конструювати апаратне забезпечення, яке може безпосередньо виконувати програми цього рівня (рівня архітектури команд). Рівень архітектури команд зв'язує компілятори і апаратне забезпечення. Це мова, яка зрозуміла і компіляторам, і апаратному забезпеченню. На мал. 8.1 показаний взаємозв'язок компіляторів, рівня архітектури команд і апаратного забезпечення.
У ідеалі при створенні нової машини розробники архітектури команд повинні консультуватися і з укладачами компіляторів, і з тими, хто конструює апаратне забезпечення, щоб з'ясувати, якими особливостями повинен володіти рівень команд. Якщо укладачі компілятора вимагають наявності якоїсь особливості, яку інженери не можуть реалізувати, то така ідея не пройде. Так само, якщо розробники апаратного забезпечення хочуть ввести в комп'ютер яку-небудь нову особливість, але укладачі програмного забезпечення не знають, як побудувати програму, щоб використовувати цю особливість, то такий проект не буде ніколи втілений. Після довгих обговорень і моделювання з'явиться рівень команд, оптимізований для потрібних мов програмування, який і буде реалізований.
Але все це в теорії. А зараз перейдемо до суворої реальності. Коли з'являється нова машина, перше питання, яке задають всі потенційні покупці: «Чи сумісна машина з попередніми версіями?». Друге питання: «Чи можу я запустити на ній мою стару операційну систему?» І третє питання: «Чи працюватимуть мої прикладні програми на цій машині і чи не буде потрібно їх змінювати?» Якщо яке-небудь з цих питань одержує відповідь «немає», розробники повинні будуть пояснити, чому. Покупці рідко рвуться викинути все старе програмне забезпечення і почати все наново.
Мал. 8.1 - Рівень команд – це проміжна ланка між компіляторами і апаратним забезпеченням.
Цей факт примушує комп'ютерних розробників зберігати один і той же рівень команд в різних моделях або, принаймні, робити його назад сумісним. Під зворотною сумісністю ми розуміємо здатність нової машини виконувати старі програми без змін. Проте нова машина може містити нові команди і інші особливості, які можуть використовуватися новим програмним забезпеченням. Розробники повинні робити рівень команд сумісним з попередніми моделями, але вони мають право творити все що завгодно з апаратним забезпеченням, оскільки навряд чи кого-небудь з покупців хвилює, що є реальним апаратним забезпеченням і якими діями воно виконує. Вони можуть переходити від мікропрограмної розробки до безпосереднього виконання, додавати конвейєри, суперскалярні пристрої і т. п., при умові що збережеться зворотна сумісність з попереднім рівнем команд. Основна мета — переконатися, що старі програми працюють на новій машині. Тоді виникає проблема: побудова кращих машин, але із зворотною сумісністю.
Все це зовсім не значить, що розробка рівня команд не має ніякого значення. Добре розроблений рівень архітектури команд має величезні переваги перед поганим, особливо відносно обчислювальних можливостей і вартості. Продуктивність еквівалентних машин з різними рівнями команд може розрізнятися на 25%. Ми просто хочемо сказати, що ринок дещо ускладнює (хоча і не робить неможливим) усунення старої архітектури команд і введення нової. Проте іноді з'являються нові рівні команд універсального призначення, а на спеціалізованих ринках (наприклад, на ринку вбудованих систем або на ринку мультимедійних процесорів) вони виникають набагато частіше. Отже, важливо розуміти принципи розробки цього рівня .
Інша важлива якість рівня команд полягає в тому, що в більшості машин є, принаймні, два режими. Привілейований режим призначений для запуску операційної системи. Він дозволяє виконувати всі команди. Призначений для користувача режим призначений для запуску програмних додатків. Цей режим не дозволяє виконувати деякі чутливі команди (наприклад, ті, які безпосередньо маніпулюють кеш-пам'яттю). В цьому розділі ми в першу чергу зосередимося на командах і властивостях призначеного для користувача режиму.