Тип команди | Фаза конвеєра | |||||||
Цілочисельна | IF | ID | EX | MEM | WB | |||
ПК | IF | ID | EX | MEM | WB | |||
Ц | IF | ID | EX | MEM | WB | |||
ПК | IF | ID | EX | MEM | WB | |||
Ц | IF | ID | EX | MEM | WB | |||
ПК | IF | ID | EX | MEM | WB | |||
Ц | IF | ID | EX | MEM | WB | |||
ПК | IF | ID | EX | MEM | WB |
Такий конвеєр дозволяє суттєво збільшити швидкість видачі команд. Але для того щоб він працював, необхідно мати або повністю конвеєризовані пристрої роботи з плаваючою комою, або відповідну кількість незалежних функціональних пристроїв. У противному випадку пристрій ПК стане вузьким місцем і ефект паралельної видачі команд зведеться до мінімуму.
При паралельній видачі двох операцій (цілочисельної та ПТ) потреба в додатковій апаратурі мінімальна: цілочисельні та пристрої ПК використовують різні функціональні пристрої та різні набори регістрів. Єдина складність виникає, тільки якщо команди представляють собою команди завантаження, запису або пересилки даних з ПК. Ці команди створюють конфлікти по регістрових портах регістрів з плаваючою комою.
Проблема регістрових портів може бути вирішена, наприклад, шляхом реалізації окремої видачі команд завантаження, запису та пересилки команд з ПК. У випадку складання пари зі звичайною операцією з ПК ситуацію можна розглядати як структурний конфлікт. Таку схему легко реалізувати, але вона буде мати суттєвий вплив на загальну швидкодію. Конфлікт такого типу може бути усунений реалізацією у регістровому файлі двох додаткових портів (для читання та запису).
Якщо пара команд складається із команди завантаження ПК та операції з ПК, яка від неї залежить, необхідно виявити подібний конфлікт та блокувати видачу команди операції з ПК. За виключенням цього випадку, всі інші конфлікти можуть виникати як у машині, що забезпечує видачу однієї команди за такт. Для запобігання зупинок можуть знадобитись додаткові ланцюги обходу.
Іншою проблемою, яка може обмежити ефективність суперскалярної обробки, є затримка завантаження даних з пам‘яті. У нашому прикладі простого конвеєра команди завантаження мали затримку в один такт, що не дозволяло наступній команді скористатись результатами завантаження без зупинки. У суперскалярному конвеєрі результат завантаження не може бути використаний у тому ж самому або у наступному такті. Це значить, що наступні три команди не можуть використовувати результат завантаження без зупинки. Затримка переходу також складає 3 такти, оскільки команда переходу повинна бути першою у парі команд. Щоб більш ефективно використовувати паралелізм, доступний на суперскалярній машині, треба використовувати більш складні методи планування потоку команд, що використовуються компілятором та апаратними засобами, та складніші схеми декодування команд.
Розглянемо наприклад, який ефект дає розгортання циклів та планування потоку команд для суперскалярного конвеєра:
Loop:LDF0,0(R1)
ADDF4,F0,F2
SD0(R1),F4
SUBR1,R1,#8
BNEZR1,Loop
Щоб спланувати цей цикл для роботи без затримок, необхідно його розгорнути та зробити 5 копій тіла циклу. Після такого розгортання цикл буде мати по п‘ять команд LD, ADD, SD, а також одну команду SUB та один умовний перехід BNEZ. Розгорнута та оптимізована програма для цього циклу може виглядати так:
Цілочисельна команда | Команда ПК | Номер такту |
Loop:LDF0,0(R1) | 1 | |
LDF8,-8(R1) | 2 | |
LDF10,-16(R1) | 3 | |
LDF14,-24(R1) | 4 | |
LDF18,-32(R1) | ADDF4,F0,F2 | 5 |
SD0(R1),F4 | ADDF8,F6,F2 | 6 |
SD-8(R1),F8 | ADDF12,F10,F2 | 7 |
SD-16(R1),F12 | ADDF16,F14,F2 | 8 |
SD-24(R1),F16 | ADDF20,F18,F2 | 9 |
SUBR1,R1,#40 | 10 | |
BNEZR1,Loop | 11 | |
SD-32(R1),F20 | 12 |
Цей розгорнутий суперскалярний цикл тепер працює із швидкістю 12 тактів на ітерацію, або 2.4 такти на один елемент – у порівнянні з 3.5 тактами у несуперскалярній архітектурі. У цьому прикладі прирощення швидкодії обмежене невеликою кількістю операцій з ПК.
У кращому випадку такий конвеєр дозволить виконувати одночасно дві команди якщо перша з них є цілочисельною, а друга – командою з ПК. Якщо ця умова не забезпечується, команди виконуються послідовно. Це показує 2 головні переваги суперскалярної архітектури над архітектурою VLIW. По-перше, малий вплив на щільність коду, оскільки машина сама з‘ясовує, чи може бути виконана наступна команда і нема потреби слідкувати за тим, щоб команди відповідали можливостям видачі. По-друге, на таких машинах можуть працювати неоптимізовані програми, тобто програми відкомпільовані для старої моделі процесора. Зрозуміло, ці програми не будуть працювати дуже швидко, але можна застосувати засоби динамічної оптимізації.
В загальному випадку у суперскалярній системі команди можуть виконуватись паралельно і не в тому порядку, в якому вони знаходяться у програмі. Якщо не вживати ніяких додаткових заходів, таке невпорядковане виконання команд та наявність багатьох функціональних пристроїв з різним часом виконання операцій може привести до додаткових труднощів. Наприклад, при виконанні деякої довгої команди з ПК (обчислення квадратного кореня) може виникнути помилка вже після того, як закінчилась більш швидка операція яка йшла після цієї операції. Для того, щоб гарантувати модель точних переривань, апаратура повинна гарантувати коректний стан процесора на момент виникнення переривань для організації наступного повернення.
Часто в машинах з невпорядкованим виконанням команд передбачені додаткові буферні схеми, які гарантують завершення команд у тому порядку, в якому вони знаходились у програмі. Такі схеми представляють собою деякій буфер "історії", тобто апаратну чергу, у яку заносяться команди та результати їх виконання у передбаченому програмою порядку.