Конфлікти в конвеєріКонфлікти в конвеєрі (англ. pipeline hazards) — ситуації, які спричиняють неможливість повного завантаження конвеєра та ефективне його функціонування. Розрізняють три класи таких конфліктів:
Структурні конфліктиСтруктурні конфлікти (англ. structural hazards) в конвеєрі виникають частіше за все там, де функціональні пристрої, які відповідають безпосередньо за обчислення, конвеєризовані не повністю, або кількість їх недостатня для виконання довільної комбінації завантажених в конвеєр машинних команд. ![]() На малюнку зображена ситуація, яка спричиняє структурний конфлікт. Тут припускається, що процесор має лише один пристрій для здійснення операції множення, який виконує цю операцію за два машинних цикли та, відповідно, не допускає дальшого подрібнення на окремі стадії. Стадія ж конвеєра має тривалість одного машинного циклу. В конвеєр послідовно завантажені дві команди множення, які не мають конфліктів даних, але суміщення виконання цих команд на стадії безпосереднього множення є неможливим, адже не може бути забезпечено розділення між ними пристрою множення. Тому для другої з команд конвеєр зупиняється на один машинний цикл. Для того, щоби уникнути такої зупинки, в склад процесора може бути введений додатковий пристрій множення, або конвеєризований наявний чи прискорена його швидкодія (доведена до тривалості одного циклу конвеєра). Конфлікти данихКонфлікти даних (англ. data hazards) — конфлікти, які виникають в випадках, коли існують залежності між даними в різних командах, які знаходяться в конвеєрі. Є три варіанти залежності:
Читання після записуПриклад i1. R2 <- R1 + R3 Способи вирішення
Конфлікти керуванняКонфлікти керування (англ. control hazards) — різновид конфліктів в конвеєрі, спричинених особливостями конвеєрного виконання команд переходу. Нехай i та j — дві машинні команди, і j в програмі є наступною за i. Кажуть[джерело?], що j залежить за переходом від i, коли рішення про необхідність виконання чи невиконання j приймається на основі результату, отриманого під час виконання i. Тобто, j залежить від i за переходом, якщо i — команда переходу. Проблематичність конвеєрного виконання таких фрагментів програмного коду полягає в тому, що заздалегідь невідомо, виконання якої команди почнеться в результаті переходу (тобто відбудеться він чи ні). У випадку послідовного (неконвеєризованого) виконання, рішення про перехід отримується до того, як наступна команда буде завантажена в виконавчий пристрій. Але в конвеєрній моделі етапи виконання різних команд суміщаються в часі, тобто етап безпосереднього обчислення результату однієї команди суміщається з завантаженням наступної і т. д., і є неможливим дізнатись в процесі цього завантаження, чи потрібне воно взагалі, адже результат команди переходу ще не обчислений. ![]() Ця ситуація зображена на малюнку. Для такого конвеєра виконання переходу означає зупинку конвеєра на три такти, щоби вивантажити непотрібні тепер команди і завантажити необхідні з іншої гілки програми. Очевидно, що чим більше стадій в конвеєрі, і чим віддаленіша від початку стадія обчислення адреси переходу, тим значнішими будуть втрати швидкодії. Див. також
Примітки
|
Portal di Ensiklopedia Dunia