Загальні відомості про рівень архітектури команд

План

Контрольні питання.

1. Дайте визначення «спекулятивне виконання команд.

2. Дайте визначення «перейменування регістрів».

3. Поясните призначення команди SPECULATIVE-LOAD.

1. Загальні відомості про рівень архітектури команд

2. Властивості рівня команд.

Рівень архітектури команд розташований між мікроархітектурним рівнем і рівнем операційної системи, як показано на мал. 1.2. Історично цей рівень розвився раніше всіх інших рівнів і споконвічно був єдиним. У наші дні цей рівень дуже часто називають «архітектурою» машини, а іноді (що неправильно) «мовою асемблера».

Рівень архітектури команд має особливе значення: він є сполучною ланкою між програмним і апаратним забезпеченням. Звичайно, можна було б зробити так, щоб апаратне забезпечення відразу безпосереднє виконувало програми, написані на З, C++, FORTRAN 90 або інших мовах високого рівня, але це не дуже гарна ідея. Перевага компіляції перед інтерпретацією було б тоді загублене. Крім того, із чисто практичних міркувань комп'ютери повинні вміти виконувати програми, написані на різних мовах, а не тільки на одному.

По суті, усі розроблювачі вважають, що потрібно транслювати програми, написані на різних мовах високого рівня, у загальну проміжну форму — на рівень архітектури команд — і відповідно конструювати апаратне забезпечення, яке може безпосередньо виконувати програми цього рівня (рівня архітектури команд). Рівень архітектури команд зв'язує компілятори й апаратне забезпечення. Це мова, яка зрозуміла й компіляторам, і апаратному забезпеченню. На мал. 5.1 показаний взаємозв'язок компіляторів, рівня архітектури команд і апаратного забезпечення.

В ідеалі при створенні нової машини розроблювачі архітектури команд повинні консультуватися й з укладачами компіляторів, і з тими, хто конструює апаратне забезпечення, щоб з'ясувати, якими особливостями повинен мати рівень команд. Якщо укладачі компілятора вимагають наявності якоїсь особливості, яку інженери не можуть реалізувати, то така ідея не пройде. Точно так само, якщо розроблювачі апаратного забезпечення прагнуть увести в комп'ютер яку-небудь нову особливість, але укладачі програмного забезпечення не знають, як побудувати програму, щоб використовувати цю особливість, те такий проект ніколи не буде втілений. Після довгих обговорень і моделювання з'явиться рівень команд, оптимізований для потрібних мов програмування, який і буде реалізований.

Але все це в теорії. А тепер перейдемо до суворої реальності. Коли з'являється нова машина, перше питання, яке задають усі потенційні покупці: «чи Сумісна машина з попередніми версіями?». Друге питання: «чи Можу я запустити на ній мою стару операційну систему?» І третє питання: «чи Будуть працювати мої прикладні програми на цій машині й не чи знадобиться їх змінювати?» Якщо який-небудь із цих питань одержує відповідь «ні», розроблювачі повинні будуть пояснити, чому. Покупці рідко рвуться викинути все старе програмне забезпечення й почати всі заново. Цей факт змушує комп'ютерних розроблювачів зберігати той самий рівень команд у різних моделях або, принаймні, робити його назад сумісним. Під зворотною сумісністю ми розуміємо здатність нової машини виконувати старі програми без змін. Проте нова машина може містити нові команди й інші особливості, які можуть використовуватися новим програмним забезпеченням. Розроблювачі повинні робити рівень команд сумісним з попередніми моделями, але вони має право творити всі що завгодно з апаратним забезпеченням, оскільки чи ледь кого-небудь із покупців хвилює, що собою представляє реальне апаратне забезпечення і які дії воно виконує. Вони можуть переходити від мікропрограмної розробки до безпосереднього виконання, додавати конвеєри, суперскалярні пристрої й т.п., за умови що збережеться зворотна сумісність із попереднім рівнем команд. Основна мета — переконатися, що старі програми працюють на новій машині. Тоді виникає проблема: побудова кращих машин, але зі зворотною сумісністю.

Усе це зовсім не виходить, що розробка рівня команд не має ніякого значення. Добре розроблений рівень архітектури команд має величезні переваги перед поганим, особливо відносно обчислювальних можливостей і вартості. Продуктивність еквівалентних машин з різними рівнями команд може різнитися на 25%. Ми просто прагнемо сказати, що ринок трохи утрудняє (хоча й не унеможливлює) усунення старої архітектури команд і введення нової. Проте іноді з'являються нові рівні команд універсального призначення, а на спеціалізованих ринках (наприклад, на ринку вбудованих систем або на ринку мультимедійних процесорів) вони виникають набагато частіше. Отже, важливо розуміти принципи розробки цього рівня.

Яку архітектуру команд можна вважати гарної? Існує два основні фактори. По-перше, гарна архітектура повинна визначати набір команд, які можна ефективно реалізувати в сучасній і майбутній техніці, що приводить до рентабельних розробок на кілька поколінь. Поганий проект реалізувати складніше. При погано розробленій архітектурі команд може знадобитися більша кількість вентилів для процесора й більший обсяг пам'яті для виконання програм. Крім того, машина може працювати повільніше, оскільки така архітектура команд погіршує можливості перекривання операцій, тому для досягнення більш високої продуктивності тут буде потрібно більш складний проект. Розробка, у якій використовуються особливості конкретної техніки, може викликати виробництво цілого покоління комп'ютерів, і ці комп'ютери зможе випередити тільки більш просунута архітектура команд.

По-друге, гарна архітектура команд повинна забезпечувати ясну мету для оттранслированной програми. Регулярність і повнота варіантів — важливі риси, які не завжди властиві архітектурі команд. Ці якості важливі для компілятора, якому важко зробити кращий вибір з декількох можливих, особливо коли деякі очевидні на перший погляд варіанти не дозволені архітектурою команд. Якщо говорити коротко, оскільки рівень команд є проміжною ланкою між апаратним і програмним забезпеченням, він повинен бути зручний і для розроблювачів апаратного забезпечення, і для укладачів програмного забезпечення.

Дата добавления: 2014-01-05