8.2. Загальний огляд рівня архітектури команд

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

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

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

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

Для однієї архітектури рівень команд визначається формальним документом, який звичайно випускається промисловим консорціумом, для інших — немає. Наприклад, V9 SPARC(Version 9 SPARC) і JVM мають офіційні визначення [156, 85]. Мета такого офіційного документа — дати можливість різним виробникам випускати машини даного конкретного виду, щоб ці машини могли виконувати одні і ті ж програми і одержувати при цьому одні і ті ж результати.

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

У таких документах містяться нормативні розділи, в яких висловлюються вимоги, і інформативні розділи, які призначені для того, щоб допомогти читачу, але не є частиною формального визначення. В нормативних розділах описані вимоги і заборони. Наприклад, такий вислів, як:

виконання зарезервованого коду операції повинне викликати системне переривання

означає, що якщо програма виконує код операції, який не визначений, то він повинен викликати системне переривання, а не просто ігноруватися. Може бути і альтернативний підхід:

результат виконання зарезервованого коду операції визначається реалізацією.

Це значить, що складач компілятора не може прорахувати якісь конкретні дії, надаючи конструкторам свободу вибору. До опису архітектури часто додаються тестові комплекти для перевірки, чи дійсно дана реалізація відповідає технічним вимогам.

Абсолютно ясно, чому V9 SPARC має документ, в якому визначається рівень команд: це потрібно для того, щоб всі мікросхеми V9 SPARC могли виконувати одні і ті ж програми. З тієї ж причини існує спеціальний документ для JVM: щоб інтерпретатори (або такі мікросхеми, як picoJava II) могли виконувати будь-яку допустиму програму JVM. Для рівня команд процесора Реntium II такого документа немає, оскільки компанія Intel не хоче, щоб інші виробники змогли запускати мікросхеми Реntium II. Компанія Intel навіть зверталася до суду, щоб заборонити виробництво своїх мікросхем іншими підприємствами.

Таким чином, існує реальна небезпека, що пам'ять не діятиме так, як очікується. Ситуація ускладнюється у випадку з мультипроцесором, коли кожен процесор посилає розділеній пам'яті потік запитів на читання і запис, які теж можуть бути переупорядковані.

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

З іншого боку, не дається взагалі ніяких гарантій. Щоб зробити звернення до пам'яті впорядкованими, програма повинна виконати команду SYNC, яка блокує запуск всіх нових операцій пам'яті до тих пір, поки попередні операції не будуть завершені. Ця ідея сильно ускладнює роботу тих, хто пише компілятори, оскільки для цього їм потрібно дуже добре знать, як працює відповідна мікроархітектура, та зате розробникам апаратного забезпечення надана повна свобода в оптимізації використання пам'яті.

Можливі також проміжні моделі пам'яті, в яких апаратне забезпечення автоматично блокує запуск певних операцій з пам'яттю (наприклад, тих, які зв'язані з RAW- або WAR-взаємозалежністю), при цьому запуск всіх інших операцій не блокується. Хоча розробка цих особливостей на рівні команд досить утомлива (принаймні, для укладачів компіляторів і програмістів на мові асемблера), зараз існує тенденція використовувати такий підхід. Ця тенденція викликана такими реалізаціями, як переупорядкування мікрокоманд, конвейєри, багаторівнева кеш-пам'ять і т.д. Інші неприродні приклади такого роду ми розглянемо в цьому розділі трохи пізніше.