4. Часова діаграма командного конвеєра

Конвейер команд

Идея конвейера команд была предложена в 1956 году академиком С. А Лебедевым. Как известно, цикл команды представляет собой последовательность этапов. Возложив реализацию каждого из них на самостоятельное устройство и последовательно соединив такие устройства, мы получим классическую схему конвейера команд. Для иллюстрации воспользуемся примером, приведенным в [200]. Выделим в цикле команды шесть этапов:

1. Выборка команды (ВК). Чтение очередной команды из памяти и занесение ее в регистр команды.

2. Декодирование команды (ДК). Определение кода операции и способов адресации операндов.

Вычисление адресов операндов (ВА). Вычисление исполнительных адресов каждого из операндов в соответствии с указанным в команде способом их адресаций.

4. Выборка операндов (ВО). Извлечение операндов из памяти. Эта операция не нужна для операндов, находящихся в регистрах.

5. Исполнение команды (ИК). Исполнение указанной операции.

6. Запись результата (ЗР), Занесение результата в память.

На рис. 9.3 показан конвейер с шестью ступенями, соответствующими шести этапам цикла команды. В диаграмме предполагается, что каждая команда обязательно проходит все шесть ступеней, хотя этот случай не совсем типичен. Так, команда загрузки регистра не требует этапа ЗР. Кроме того, здесь принято, что все этапы могут выполняться одновременно. Без конвейеризации выполнение девяти команд заняло бы 9 х 6 = 54 единицы времени. Использование конвейера позволяет сократить время обработки до 14 единиц.

5. Конфлікти в конвеєрі (англ. pipeline hazards) — ситуації, які спричиняють неможливість повного завантаження конвеєра та ефективне його функціонування.

Розрізняють три класи таких конфліктів:

Структурні конфлікти (англ. structural hazards) — виникають у випадках, коли неможливий розподіл апаратних ресурсів конвеєра між його окремими етапами для забезпечення повного його завантаження

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

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

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

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

Конфлікти даних (англ. data hazards) — виникають в випадках, коли існують залежності між даними в різних командах, які знаходяться в конвеєрі.

Конфлікти даних (англ. data hazards) — конфлікти, які виникають в випадках, коли існують залежності між даними в різних командах, які знаходяться в конвеєрі.

Є три варіанти залежності:

читання після запису, англ. read after write (RAW), справжня залежність

запис після читання, англ. write after read (WAR)

запис після запису, англ. write after write (WAW)

Конфлікти управління (англ. control hazards або англ. branching hazards) — виникають як наслідок конвеєризації команд передачі управління, які змінюють значення лічильника команд.

КОНФЛІКТИ УПРАВЛІННЯ (control hazards) - різновид конфліктів в конвеєрі, спричинених особливостями конвеєрного виконання команд передачі управління.

Нехай i та j - дві машинні команди, і j в програмі є наступною за i. Кажуть, що j залежить по управлінню від i, коли рішення про необхідність виконання чи невиконання j приймається на основі результату, отриманого під час виконання i. Тобто, j залежить від i по управлінню, якщо i - команда передачі управління.

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

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