Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекція №32
Тема: Загальний огляд рівня архітектури команд.
Ціль: Розглянути рівень архітектури команд, його призначення й властивості.
План
Загальні відомості про рівень архітектури команд
Рівень архітектури команд розташований між мікроархітектурним рівнем і рівнем операційної системи, як показано на мал. 1.2. Історично цей рівень розвився раніше всіх інших рівнів і споконвічно був єдиним. У наші дні цей рівень дуже часто називають «архітектурою» машини, а іноді (що неправильно) «мовою асемблера».
Рівень архітектури команд має особливе значення: він є сполучною ланкою між програмним і апаратним забезпеченням. Звичайно, можна було б зробити так, щоб апаратне забезпечення відразу безпосереднє виконувало програми, написані на З, C++, FORTRAN 90 або інших мовах високого рівня, але це не дуже гарна ідея. Перевага компіляції перед інтерпретацією було б тоді загублене. Крім того, із чисто практичних міркувань комп'ютери повинні вміти виконувати програми, написані на різних мовах, а не тільки на одному.
По суті, усі розроблювачі вважають, що потрібно транслювати програми, написані на різних мовах високого рівня, у загальну проміжну форму — на рівень архітектури команд — і відповідно конструювати апаратне забезпечення, яке може безпосередньо виконувати програми цього рівня (рівня архітектури команд). Рівень архітектури команд зв'язує компілятори й апаратне забезпечення. Це мова, яка зрозуміла й компіляторам, і апаратному забезпеченню. На мал. 5.1 показаний взаємозв'язок компіляторів, рівня архітектури команд і апаратного забезпечення.
В ідеалі при створенні нової машини розроблювачі архітектури команд повинні консультуватися й з укладачами компіляторів, і з тими, хто конструює апаратне забезпечення, щоб з'ясувати, якими особливостями повинен мати рівень команд. Якщо укладачі компілятора вимагають наявності якоїсь особливості, яку інженери не можуть реалізувати, то така ідея не пройде. Точно так само, якщо розроблювачі апаратного забезпечення прагнуть увести в комп'ютер яку-небудь нову особливість, але укладачі програмного забезпечення не знають, як побудувати програму, щоб використовувати цю особливість, те такий проект ніколи не буде втілений. Після довгих обговорень і моделювання з'явиться рівень команд, оптимізований для потрібних мов програмування, який і буде реалізований.
Але все це в теорії. А тепер перейдемо до суворої реальності. Коли з'являється нова машина, перше питання, яке задають усі потенційні покупці: « чи Сумісна машина з попередніми версіями?». Друге питання: « чи Можу я запустити на ній мою стару операційну систему?» І третє питання: « чи Будуть працювати мої прикладні програми на цій машині й не чи знадобиться їх змінювати?» Якщо який-небудь із цих питань одержує відповідь «ні», розроблювачі повинні будуть пояснити, чому. Покупці рідко рвуться викинути все старе програмне забезпечення й почати всі заново. Цей факт змушує комп'ютерних розроблювачів зберігати той самий рівень команд у різних моделях або, принаймні, робити його назад сумісним. Під зворотною сумісністю ми розуміємо здатність нової машини виконувати старі програми без змін. Проте нова машина може містити нові команди й інші особливості, які можуть використовуватися новим програмним забезпеченням. Розроблювачі повинні робити рівень команд сумісним з попередніми моделями, але вони має право творити всі що завгодно з апаратним забезпеченням, оскільки чи ледь кого-небудь із покупців хвилює, що собою представляє реальне апаратне забезпечення і які дії воно виконує. Вони можуть переходити від мікропрограмної розробки до безпосереднього виконання, додавати конвеєри, суперскалярні пристрої й т.п., за умови що збережеться зворотна сумісність із попереднім рівнем команд. Основна мета — переконатися, що старі програми працюють на новій машині. Тоді виникає проблема: побудова кращих машин, але зі зворотною сумісністю.
Усе це зовсім не виходить, що розробка рівня команд не має ніякого значення. Добре розроблений рівень архітектури команд має величезні переваги перед поганим, особливо відносно обчислювальних можливостей і вартості. Продуктивність еквівалентних машин з різними рівнями команд може різнитися на 25%. Ми просто прагнемо сказати, що ринок трохи утрудняє (хоча й не унеможливлює) усунення старої архітектури команд і введення нової. Проте іноді з'являються нові рівні команд універсального призначення, а на спеціалізованих ринках (наприклад, на ринку вбудованих систем або на ринку мультимедійних процесорів) вони виникають набагато частіше. Отже, важливо розуміти принципи розробки цього рівня.
Яку архітектуру команд можна вважати гарної? Існує два основні фактори. По-перше, гарна архітектура повинна визначати набір команд, які можна ефективно реалізувати в сучасній і майбутній техніці, що приводить до рентабельних розробок на кілька поколінь. Поганий проект реалізувати складніше. При погано розробленій архітектурі команд може знадобитися більша кількість вентилів для процесора й більший обсяг пам'яті для виконання програм. Крім того, машина може працювати повільніше, оскільки така архітектура команд погіршує можливості перекривання операцій, тому для досягнення більш високої продуктивності тут буде потрібно більш складний проект. Розробка, у якій використовуються особливості конкретної техніки, може викликати виробництво цілого покоління комп'ютерів, і ці комп'ютери зможе випередити тільки більш просунута архітектура команд.
По-друге, гарна архітектура команд повинна забезпечувати ясну мету для оттранслированной програми. Регулярність і повнота варіантів — важливі риси, які не завжди властиві архітектурі команд. Ці якості важливі для компілятора, якому важко зробити кращий вибір з декількох можливих, особливо коли деякі очевидні на перший погляд варіанти не дозволені архітектурою команд. Якщо говорити коротко, оскільки рівень команд є проміжною ланкою між апаратним і програмним забезпеченням, він повинен бути зручний і для розроблювачів апаратного забезпечення, і для укладачів програмного забезпечення.
Властивості рівня команд
У принципі рівень команд — це те, яким представляється комп'ютер програмістові машинної мови. Оскільки зараз жодна нормальна людина не пише програм машинною мовою, ми переробили це визначення. Програма рівня архітектури команд — це те, що видає компілятор ( у цей момент ми ігноруємо виклики операційної системи й символічна мова асемблера). Щоб зробити програму рівня команд, укладач компілятора повинен знати, яка модель пам'яті використовується в машині, які регістри, типи даних і команди є в наявності і т.д. Уся ця інформація в сукупності й визначає рівень архітектури команд. Відповідно до цього визначення такі питання, як чи програмується мікроархітектура чи ні, конвеєризований комп'ютер чи ні, є він суперскалярним чи ні і т.д., не ставляться до рівня архітектури команд, оскільки укладач компілятора не бачить усього цього. Однак це зауваження не зовсім слушне, оскільки деякі із цих властивостей впливають на продуктивність, а продуктивність є видимою для програміста. Розглянемо, наприклад, суперскалярну машину, яка може видавати back-to-back команди в одному циклі, за умови що одна команда целочисленная, а одна — із плаваючою крапкою. Якщо компілятор чергує целочисленные команди й команди із плаваючою крапкою, то продуктивність помітно покращиться. Таким чином, деталі суперскалярної операції видні на рівні команд, і границі між різними рівнями розмиті.
Для одних архитектур рівень команд визначається формальним документом, який звичайно випускається промисловим консорціумом, для інших — немає. Наприклад, V9 SPARC (Version 9 SPARC) і JVM мають офіційні визначення. Ціль такого офіційного документа — дати можливість різним виробникам випускати машини даного конкретного виду, щоб ці машини могли виконувати ті самі програми й одержувати при цьому ті самі результати. У випадку із системою SPARC подібні документи потрібні для того, щоб різні підприємства могли випускати ідентичні мікросхеми SPARC, що відрізняються друг від друга тільки продуктивністю й ціною. Щоб ця ідея працювала, постачальники мікросхем повинні знати, що робить мікросхема SPARC (на рівні команд). Отже, у документі говориться про те, яка модель пам'яті, які регістри присутні, які дії виконують команди і т.д., а не про те, що являє собою мікроархітектура.
У таких документах утримуються нормативні розділи, у яких викладаються вимоги, і інформативні розділи, які призначені для того, щоб допомогти читачеві, але не є частиною формального визначення. У нормативних розділах описані вимоги й заборони. Наприклад, таке висловлення, як:
виконання зарезервованого коду операції повинне викликати системне переривання
означає, що якщо програма виконує код операції, який не визначений, то він повинен викликати системне переривання, а не просто ігноруватися. Може бути й альтернативний підхід:
результат виконання зарезервованого коду операції визначається реалізацією.
Це значить, що укладач компілятора не може прорахувати якісь конкретні дії, надаючи конструкторам свободу вибору. До опису архітектури часто додаються тестові комплекти для перевірки, чи дійсно дана реалізація відповідає технічним вимогам.
Інша важлива якість рівня команд полягає в тому, що в більшості машин є, принаймні, два режими. **Привілейований режим** призначений для запуску операційної системи. Він дозволяє виконувати всі команди. **Користувацький режим** призначений для запуску програмних додатків. Цей режим не дозволяє виконувати деякі чутливі команди (наприклад, ті, які безпосередньо маніпулюють кеш-пам'яттю). У цій главі ми в першу чергу зосередимося на командах і властивостях користувацького режиму. == Моделі пам'яті == У всіх комп'ютерах пам'яті розділена на гнізда, які мають послідовні адреси. У цей час найпоширеніший розмір гнізда — 8 битов, але раніше використовувалися гнізда від 1 до 60 битов. Гніздо з 8 битов називається байтом. Причина застосування саме 8-бітних байтів така: символи ASCII коду займають 7 битов, тому один символ ASCII плюс біт парності саме підходить під розмір байта. Якщо в майбутньому буде домінувати UNICODE, то комірки пам'яті, можливо, будуть 16-бітними. Загалом кажучи, число 24 краще, чим 23, оскільки 4 — ступінь двійки, а 3 — немає. Байти звичайно групуються в 4-байтные ( 32-бітні) або 8-байтные ( 64-бітні) слова з командами для маніпулювання цілими словами. Багато архітектури вимагають, щоб слова були вирівняні у своїх природніх границях. Так, наприклад, 4-байтное слово може починатися з адреси 0,4,8 і т.д., але не з адреси 1 або 2. Точно так само слово з 8 байтів може починатися з адреси 0,8 або 16, але не з адреси 4 або 6. Розташування 8-байтных слів показане на мал. 5.2. Вирівнювання адрес потрібно досить часто, оскільки при цьому пам'ять працює більш ефективно. Наприклад, Pentium II, який викликає з пам'яті по 8 байтів за раз, використовує 36-бітні фізичні адреси, але містить тільки 33 адресних біта, як показано на мал. 3.41. Отже, Pentium II навіть не зможе звернутися до невирівняної пам'яті, оскільки молодші три біти не визначені явно. Ці біти завжди рівні 0, і всі адреси пам'яті кратні 8 байтам. Проте вимога вирівнювання адрес іноді викликає деякі проблеми. У процесорі Pentium II програми можуть звертатися до слів, починаючи з будь-якої адреси, — це якість сходить до моделі 8088 із шиною даних шириною в 1 байт, у якій не було такої вимоги, щоб гнізда розташовувалися в 8-байтных границях. Якщо програма в процесорі Pentium II зчитує 4-байтное слово з адреси 7, апаратне забезпечення повинне зробити одне звертання до пам'яті, щоб викликати байти з 0-го по 7-й, і друге звертання до пам'яті, щоб викликати байти з 8-го по 15-й. Потім центральний процесор повинен витягти необхідні 4 байта з 16 байтів, лічених з пам'яті, і скомпонувати їх у потрібному порядку, щоб сформувати 4-байтное слово. Можливість зчитувати слова з довільними адресами вимагає ускладнення мікросхеми, яка після цього стає більше по розміру й дорожче. Розроблювачі були б раді позбутися такої мікросхеми й просто зажадати, щоб усі програми зверталися до слів пам'ятей, а не до байтів. Однак на запитання інженерів: «Кому потрібно виконання старих програм для машини 8088, які неправильно звертаються до пам'ятей?» піде відповідь продавців: «Нашим покупцям». Більшість машин мають єдиний лінійний адресний простір, який простягнеться від адреси 0 до якогось максимуму, звичайно 232 байтів або 2мбайтів. У деяких машинах утримуються окремі адресні простори для команд і для даних, так що при виклику команди з адресою 8 і виклику даних з адресою 8 відбувається звертання до різних адресних просторів. Така система набагато складніше, чим єдиний адресний простір, але зате вона має дві переваги. По-перше, з'являється можливість мати 232 байтів для програми й додаткові 232 байтів для даних, використовуючи тільки 32-бітні адреси. По-друге, оскільки запис завжди автоматично відбувається тільки в простір даних, випадковий перезапис програми стає неможливою, і отже, усувається один із джерел програмних збоїв. Відзначимо, що окремі адресні простори для команд і для даних — це не те ж саме, що розділена кеш-пам'ять першого рівня. У першому випадку весь адресний простір цілком дублюється, і зчитування з будь-якої адреси викликає різні результати залежно від того, що саме зчитується: слово або команда. При розділеній кеш-пам'яті існує тільки один адресний простір, просто в різних блоках кеш-пам'яті зберігаються різні частини цього простору. Ще один аспект моделі пам'яті — семантика пам'яті. Природно очікувати, що команда LOAD, яка зустрічається після команди STORE і яка звертається до того ж адреси, поверне тільки що збережене значення. Проте, як ми бачили в главі 4, у багатьох машинах мікрокоманди переупорядковуються. Таким чином, існує реальна небезпека, що пам'ять не буде діяти так, як очікується. Ситуація ускладнюється у випадку з мультипроцесором, коли кожний процесор посилає розділеної пам'яті потік запитів на читання й запис, які теж можуть бути переупорядковані. Системні розроблювачі можуть застосовувати один з декількох підходів до цієї проблеми. З одного боку, усі запити пам'яті можуть бути впорядковані в послідовність таким чином, щоб кожний з них завершувався до того, як почнеться наступний. Така стратегія сильно шкодить продуктивності, але зате дає найпростішу семантику пам'яті (усі операції виконуються в строгому програмному порядку). З іншого боку, не дається взагалі ніяких гарантій. Щоб зробити звертання до пам'яті впорядкованими, програма повинна виконати команду SYNC, яка блокує запуск усіх нових операцій пам'яті доти, поки попередні операції не будуть завершені. Ця ідея сильно утрудняє роботу тих, хто пише компілятори, оскільки для цього їм потрібно дуже добре знати, як працює відповідна мікроархітектура, але зате розроблювачам апаратного забезпечення надана повна воля в оптимізації використання пам'яті. Можливі також проміжні моделі пам'яті, у яких апаратне забезпечення автоматично блокує запуск певних операцій з пам'яттю (наприклад, тих, які пов'язані з RAW- або War-Взаємозалежністю), при цьому запуск усіх інших операцій не блокується. Хоча розробка цих особливостей на рівні команд досить стомлююча ( принаймні, для укладачів компіляторів і програмістів мовою асемблера), зараз існує тенденція використовувати такий підхід. Ця тенденція викликана такими реалізаціями, як переупорядкування мікрокоманд, конвеєри, багаторівнева кеш-пам'ять і т.д.
Контрольні питання