Структурні конфлікти можуть виникати, наприклад у машинах, які мають єдиний конвеєр пам‘яті для команд та даних. У цьому випадку коли команда буде містити звернення до пам‘яті за даними, воно буде конфліктувати з вибіркою наступної команди з пам‘яті. Щоб вирішити таку проблему, достатньо просто призупинити конвеєр на один такт, коли відбувається звернення до пам‘яті за даними. Подібна зупинка називається "конвеєрною бульбашкою" оскільки бульбашка проходить по конвеєру, займаючи місце, але не виконуючи ніякої корисної роботи:
| Команда | Номер такту | |||||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | |
| Команда завантаження | IF | ID | EX | MEM | WB | |||||
| Команда 1 | IF | ID | EX | MEM | WB | |||||
| Команда 2 | IF | ID | EX | MEM | WB | |||||
| Команда 3 | Stall | IF | ID | EX | MEM | WB | ||||
| Команда 4 | IF | ID | EX | MEM | WB | |||||
| Команда 5 | IF | ID | EX | MEM | ||||||
| Команда 6 | IF | ID | EX | |||||||
В загальному випадку, машина без структурних конфліктів буде мати менший CPI (середня кількість тактів на виконання однієї інструкції). Виникає питання: чому розроблювачі процесорів допускають появу структурних конфліктів? Є дві причини для цього: зменшення ціни на процесор та зменшення затримок пристрою. Конвеєризація всіх функціональних пристроїв може бути дуже коштовною. Машини, що мають можливість одночасного звернення до пам‘яті, мають подвоєну пропускну здатність пам‘яті наприклад шляхом розділення кешей для даних та для команд. Як правило, можливо спроектувати не конвеєрний або не повністю конвеєрний пристрій, який би мав менший CPI ніж повністю конвеєрний пристрій. Наприклад, розроблювачі машин CDC7600 та MIPS R2010 віддали перевагу меншій затримці виконання конвеєрних операцій замість повної конвеєризації.
Одним з факторів, які мають суттєвий вплив на швидкодію процесора, є міжкомандні логічні залежності. Такі залежності суттєво скорочують ступінь паралелізму, якого можна було б досягти. Ступінь впливу цих залежностей залежить як від архітектури процесора, так і від характеристик набору команд.
Конфлікти по даних виникають у тому випадку, коли застосування конвеєрної обробки може змінити порядок звернення за операндами таким чином, що порядок виконання команд буде відрізнятись від порядку команд, що виконувались би на неконвеєрній машині. Розглянемо конвеєрне виконання команд:
| ADD R1,R2,R3 | IF | ID | EX | MEM | WB |
| SUB R4,R1,R5 | IF | ID | EX | MEM | WB |
| AND R6,R1,R7 | IF | ID | EX | MEM | WB |
| OR R8,R1,R9 | IF | ID | EX | MEM | WB |
| XOR R10,R1,R11 | IF | ID | EX | MEM | WB |
У цьому прикладі всі команди, що слідують за командою ADD, використовують результат її виконання. Команда ADD записує результат у R1, а команда SUB читає його значення. Якщо не вживати ніяких заходів, команда SUB може прочитати невірне значення і використати його. Ця проблема може бути вирішена за допомогою достатньо простої апаратної техніки, яка називається пересилкою або переміщенням даних (data forwarding). Ця апаратура працює наступним чином: Результат операції АЛП з вихідного регістра завжди пересилається назад на входи АЛП. Якщо апаратура з‘ясовує, що попередня операція записує результат у регістр, який є одним з операндів наступної, читається значення передане на вхід АЛП, а не значення регістрового файлу.
Така техніка "обходу" може бути узагальнена для того, щоб включити передачу результату прямо в той функціональний пристрій, який його потребує.
Нажаль, не всі потенційні конфлікти по даних можуть оброблятися за допомогою механізмів "обходу". Розглянемо послідовність команд:
| Команда | ||||||
| LW R1,32(R6) | IF | ID | EX | MEM | WB | |
| ADD R4,R1,R7 | IF | ID | STALL | EX | MEM | WB |
| SUB R5,R1,R8 | IF | STALL | ID | EX | MEM | WB |
| AND R6,R1,R7 | STALL | IF | ID | EX | MEM | WB |
Команда завантаження R1 з пам‘яті має затримку, яка не може бути ліквідована звичайною "пересилкою". Замість цього нам потрібна додаткова апаратура, що називається апаратурою внутрішнього блокування конвеєра для того, щоб забезпечити коректне виконання прикладу. Взагалі така апаратура виявляє конфлікт і призупиняє конвеєр доки конфлікт не буде ліквідовано.
Багато типів зупинок конвеєра можуть траплятися досить часто. Наприклад, для оператора A = B + C компілятор генерує таку послідовність команд:
| LW R1,B | IF | ID | EX | MEM | WB | |
| LW R2,C | IF | ID | EX | MEM | WB | |
| ADD R3,R1,R2 | IF | ID | Stall | EX | MEM | WB |
| SW A,R3 | IF | Stall | ID | EX | MEM | WB |
Зрозуміло, виконання команди ADD має бути зупинено до тих пір, доки не стане доступним операнд С.
Для даного простого прикладу компілятор ніяк не може покращити ситуацію, але у багатьох інших випадках компілятор може досить суттєво впливати на ситуацію за допомогою перестановок команд. Ця техніка називається плануванням завантаження конвеєра (pipeline scheduling) або плануванням потоку команд (instruction scheduling), використовується з 60-х років і розвинулась у окрему галузь у 80-х коли з‘явилась велика кількість конвеєрних машин.
Наприклад, маємо 2 оператора на мові програмування С: a = b + c; d = e – f; Яким чином можна згенерувати послідовність команд для зменшення конфліктів по даних?
| Неоптимізована послідовність команд | Оптимізована послідовність команд |
| LW Rb,bLW Rc,cADD Ra,Rb,RcSW a,RaLW Re,eLW Rf,fSUB Rd,Re,RfSW d,Rd | LW Rb,bLW Rc,cLW Re,eADD Ra,Rb,RcLW Rf,fSW a,RaSUB Rd,Re,RfSW d,Rd |
В результаті ліквідовано блокування (командою LW Rc,c команди ADD Ra,Rb,Rc та командою LW Rf,f команди SUB Rd,Re,Rf). Мається залежність між операцією АЛП та операцією запису до пам‘яті, але структура конвеєру дозволяє запис результатів за допомогою ланцюгів обходу. Використання різних регістрів для першого та другого операторів було критичним для реалізації правильного планування. В загальному випадку планування може потребувати великої кількості регістрів. Це особливо суттєво для машин, які можуть одночасно виконувати декілька команд за один такт.
Всі сучасні компілятори використовують техніку планування завантаженості конвеєра для підвищення швидкодії згенерованих програм. У найпростішому випадку компілятор просто планує виконання команд в одному базовому блоці. Базовий блок представляє собою фрагмент програми без переходів. Планування такої послідовності відбувається досить просто, оскільки компілятор знає, що всі команди в блоці будуть виконуватись, якщо виконується перша команда блоку. У цьому випадку достатньо побудувати граф залежностей цих команд та розташувати їх таким чином, щоб мінімізувати зупинки конвеєра. Для простих конвеєрів такий алгоритм дає добрі результати, але коли конвеєризація стає більш інтенсивною, виникає потреба у більш складних алгоритмах.
Існують апаратні методи зміни порядку виконання команд для того, щоб мінімізувати зупинки конвеєра. Ці методи отримали загальну назву методів динамічної оптимізації.
Основними засобами динамічної оптимізації є
1.Розміщення схеми виявлення конфліктів у найнижчій точці конвеєра команд таким чином, щоб дозволити команді пересуватись по конвеєру до тих пір, поки їй реально не знадобиться операнд, що є також результатом логічно більш ранньої але ще не завершеної команди. Альтернативним підходом є централізоване виявлення конфліктів на ранній стадії конвеєра;
2.Буферизація команд, що очікують вирішення конфлікту, та видача наступних, логічно не зв‘язаних команд в "обхід" буфера;
3.Відповідна організація комутуючих магістралей, що забезпечує безпосередню передачу результату операції в буфер, що зберігає логічно залежну команду що було затримано внаслідок конфлікту або безпосередньо на вхід функціонального пристрою до того, як результат буде записаний у регістровий файл або в пам‘ять.
Ще одним апаратним методом мінімізації конфліктів по даних є метод перейменування регістрів (register renaming). Він отримав свою назву від широковживаного в компіляторах методу перейменування – метода розміщення даних, що сприяє скороченню залежностей між даними і тим самим підвищенню швидкодії при відображенні об‘єктів програми (змінні) на апаратні ресурси комп‘ютера (пам‘ять, регістри).
При апаратній реалізації методу перейменування регістрів виділяються логічні регістри, звернення до яких виконується за допомогою відповідного поля команди, та фізичні регістри, що знаходяться в апаратному регістровому файлі процесора. Номери логічних регістрів динамічно відображаються на номери фізичних регістрів за допомогою таблиць відображення, що відновлюються після декодування кожної команди. Кожний новий результат записується у новий фізичний регістр. Але попереднє значення логічного регістра зберігається і може бути встановлено у випадку переривання чи неправильно передбаченого умовного переходу.
У процесі виконання програми генеруються багато тимчасових регістрових результатів. Ці тимчасові результати записуються у регістровий файл разом з постійними значеннями. Тимчасове значення стає постійним коли завершується виконання команди (фіксується її результат). В свою чергу, завершення команди відбувається коли всі попередні команди успішно завершились у заданому програмою порядку.