ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 24.12.2021
Просмотров: 6828
Скачиваний: 22
174
Для забезпечення реалізації в конвеєрі випереджувального пересилання в ньому формуються додаткові канали пересилання даних з відповідними мультиплексорами для підключення входів функціональних блоків комп'ютера до цих каналів та додаткові буферні регістри
5.2.5. Статична диспетчеризація послідовності команд у програмі під час компіляції
У деяких комп'ютерах для зменшення кількості конфліктів за даними, аж до повної їх ліквідації, застосовують програмні методи, що передбачають створення оптимізуючих компіляторів, які орієнтовані на усунення можливості появи конфліктів у конвеєрі іще на стадії компіляції програми. Оптимізуючи компілятори, реорганізовують послідовність команд та створюють такий об'єктний код, щоб між конфліктуючими командами (командами, здатними до конфлікту) знаходилась достатня кількість неконфліктуючих команд. Якщо компілятору цього зробити не вдається, то він вставляє між конфліктуючими командами необхідну кількість команд типу «немає операції». Такий підхід виключає необхідність призупинення роботи конвеєра і виконання випереджувального пересилання, яке вимагає додаткових затрат обладнання та ускладнює керування
Для виявлення конфліктуючих команд в оптимізуючому компіляторі потрібно реалізувати відповідні засоби аналізу команд. Ознаками наявності конфліктів за даними є наступні
-
для конфліктів за даними типу RAW - наявність збіжностей в адресах читання попередніх команд та адресах запису наступних команд,
-
для конфліктів за даними типу WAR - наявність збіжностей в адресах запису попередніх команд та адресах читання наступних команд,
-
для конфліктів за даними типу WAW - наявність збіжностей в адресах запису попередніх команд та адресах запису7 наступних команд
Тобто оптимізуючий компілятор повинен проводити аналіз на збіжність адрес запису і читання сусідніх команд, знаходити конфліктуючі команди, та розводити їх в часі
Статична диспетчеризація послідовності команд у програмі під час компіляції використовувалася, починаючи з 60-х років минулого століття, і викликала підвищений інтерес у 80-х роках, коли конвеєрні машини стали поширенішими
Нехай, наприклад, є послідовність операторів: a = b + c;d = e-f. Нижче наведена не оптимізована програма для виконання цих операторів
LW г2,0(г0)
LW гЗ,4(гО)
ADD г4,г2,гЗ
175
SW 8(r0),r4 LW r5,12(rO) LW r6,16(rO) SUB r7,r5,r6 SW 20(r0),r7
Вхідні дані та результати цієї програми розміщені в комірках пам'яті даних, наведених в табл. 5.1.
Таблиця 5.1
|
Операнд |
Адреса комірки пам'яті |
|
a |
8 |
|
b |
0 |
|
c |
4 |
|
d |
20 |
|
e |
12 |
|
f |
16 |
Діаграма виконання програми приведена на рис. 5.9. Як видно з рисунка, тут наявні чотири затримки, викликанані залежністю за даними: друга і третя команди - звернення до регістра гЗ, третя і четверта команди - звернення до регістра г4, шоста і сьома команди - звернення до регістра гб, сьома і восьма команди - звернення до регістра г7.
Знаходимо конфліктуючі команди в наведеній вище програмі та розводемо їх в часі. Нижче наведена оптимізована програма для виконання тих же операторів
LW г2,0(г0) LW гЗ,4(гО) LW r5,12(rO) LW r6,16(rO)
ADD г4,г2,гЗ SUB г7,г5,г6 SW 8(r0),r4 SW 20(r0),r7
176
Вхідні дані та результати розміщені в тих же комірках пам'яті, приведених в табл. 5.1. Тоді діаграма виконання програми буде мати вигляд, як це приведено на рис. 5.10 (отримана з використанням симулятора WinDLX).
Як наслідок, повністю усунені два блокування (стосовно регістрів гЗ і г4), та в двох блокуваннях (стосовно гб і г7) забрано по одному такту затримки. Тобто в цілому забрано б тактів. Залежності, які залишилися, можна забрати, використавши схеми обходу.
Відзначимо, що використання різних регістрів для першого і другого операторів було достатньо важливим для реалізації такого правильного планування. Зокрема, якби змінна є була б завантажена в той же самий регістр, що b або с, то таке планування не було б коректним. У загальному випадку планування конвеєра може вимагати збільшеної кількості регістрів.
Статична диспетчеризація передбачає реорганізацію послідовності команд, серед яких відсутні команди переходу, за винятком початку і кінця цієї послідовності. Планування такої послідовності команд здійснюється досить просто, оскільки в компіляторі передбачено, що кожна наступна команда виконуватиметься, якщо виконується перша з них. Тому можна побудувати граф залежностей цих команд і впорядкувати їх так, щоб мінімізувати кількість призупинень конвеєра. Для простих конвеєрів використання статичної диспетчеризації дає цілком задовільні результати. Проте, коли довжина конвеєра збільшується і його затримки зростають, потрібні складніші алгоритми диспетчеризації.
5.2.6. Динамічна диспетчеризація послідовності команд у програмі під час компіляції
Динамічна диспетчеризація передбачає проведення компіляції програми узгоджено з процесом виконання команд в комп'ютері з метою мінімізації кількості призупинень конвеєра. У англомовній літературі разом з терміном "динамічна диспетчеризація" часто застосовуються терміни "out-of-order execution" - невпорядковане виконання і "out-of-order issue" - невпорядковане видавання, які практично завжди наявні при динамічній диспетчеризації. При динамічній оптимізації в конвеєрі команд розміщується пристрій виявлення конфліктів, який інформує компілятора про наявність конфліктів з тим, щоб він міг реагувати в процесі компіляції на ці конфлікти. Одним з варіантів реагування є
177
буферизація команд, що чекають вирішення конфлікту, і подання подальших, логічно не пов'язаних команд, в конвеєр. При цьому буферизовані команди можуть подаватися в потрібний ярус конвеєра, що забезпечується створенням в ньому комутуючих магістралей, які, крім того, забезпечують засилання результату операції безпосередньо в буфер, що зберігає логічно залежну команду, затриману через конфлікт, або безпосередньо на вхід функціонального пристрою до того, як цей результат буде записаний в регістровий файл або в пам'ять.
При динамічній диспетчеризації команди можуть подаватися на виконання не в тому порядку, в якому вони розташовані в програмі, проте засоби виявлення і усунення конфліктів між логічно зв'язаними командами мають забезпечувати отримання результатів відповідно до заданої програми.
5.2.7. Перейменування регістрів
Ще одним апаратним методом мінімізації конфліктів за даними є метод перейменування регістрів. При реалізації цього методу в адресних полях команди вказуються номери не фізичних, а логічних (уявних) регістрів. Номери логічних регістрів динамічно відображаються на номери фізичних регістрів, які розміщуються в регістровому файлі процесора, за допомогою таблиць відображення, котрі оновлюються після декодування кожної команди. Кожен новий результат записується в фізичний регістр.
Проте попереднє (тимчасове) значення кожного логічного регістра зберігається і може бути відновлене, якщо виконання команди має бути перерване через виникнення виняткової ситуації або у випадку невірного передбачення напряму умовного переходу. В процесі виконання програми генерується велика кількість тимчасових результатів. Ці тимчасові результати записуються в регістрові файли разом з постійними результатами. Тимчасовий результат стає новим постійним результатом, коли завершується виконання команди. У свою чергу, завершення виконання команди відбувається, коли виконання всіх попередніх команд успішно завершено в заданому програмою порядку.
Програміст має справу тільки з логічними регістрами. Реалізація фізичних регістрів від нього прихована.
Метод перейменування регістрів спрощує контроль залежностей за даними. У комп'ютері, який може виконувати команди не у порядку їх розташування в програмі, номери логічних регістрів можуть стати двозначними, оскільки один і той же регістр може бути призначений послідовно для зберігання різних значень. Але оскільки номери фізичних регістрів унікально ідентифікують кожен результат, всі неоднозначності усуваються.
5.3. Конфлікти керування
5.3.1. Типи конфліктів керування
Конфлікти керування можуть викликати ще більше зниження продуктивності конвеєра, ніж конфлікти за даними. Вони викликані наявністю в програмах команд керування, які змінюють хід обчислювального процесу: безумовний та умовний переходи, пропуск, виклик процедури та повернення з неї. Виконання команд керування може
178
призводити до необхідності очистки конвеєра та завантаження нової послідовності команд, що знижує його продуктивність. Те, що команда належить до команд керування, можна вияснити лише після її декодування, тобто за кілька тактів після її надходження до конвеєра (в комп'ютері DLX через 2 такти).
За цей час на перші яруси конвеєра вже надійдуть нові команди. При виявленні команди керування потрібно вияснити, чи здійснюється перехід, і якщо так, то очистити конвеєр від наступних за нею команд та завантажити команду, розміщену за адресою переходу. Для цього спочатку потрібно визначити виконавчу адресу переходу, яка може бути або безпосередньо в адресному полі команди, або її потрібно обчислити в наступних ярусах конвеєра. Таким чином, реалізація в конвеєрі команд керування вимагає виконання додаткових операцій, що рівнозначно його зупинці на відповідну кількість тактів
Особливо складною для виконання в конвеєрі є команда умовного переходу. Коли виконується команда умовного переходу, вона може або змінити вміст лічильника команд, або залишити його без змін. Якщо команда умовного переходу замінює лічильник команд значенням адреси, обчисленої в команді, то перехід називається здійснимим. В іншому випадку він називається нездійснимим. Для забезпечення опрацювання в конвеєрі команд умовного переходу потрібно передбачити проведення відповідних дій. Простий метод роботи з умовними переходами полягає в призупиненні конвеєра як тільки виявлена команда умовного переходу до тих пір, поки вона не досягне ярусу конвеєра, який обчислює нове значення лічильника команд. Реалізація цього методу для наведеного нижче фрагмента програми
dd r7,r8,rl bnez r4,$TEXT and r5,r7,r7 add r2,r2,r3
відображена на рис. 5.11, де після декодування команди BNEZ (перехід, якщо не рівний нулю) призупиняється виконання наступної команди.
Комп'ютер, в якому здійснюються призупинення при виявленні команд умовних переходів, суттєво втрачає прискорення, що одержується за рахунок конвеєрної організації. При цьому, чим більша глибина конвеєра, тим більші втрати на командах умовного переходу
Таким чином, для зменшення втрат в конвеєрі через конфлікти керування потрібно звернути увагу в першу чергу на організацію вибірки команди, до якої здійснюється перехід, та на скорочення часу виконання команд умовного переходу