18 КОНВЕЄРНЕ ВИКОНАННЯ КОМАНД

18.1 Поняття конвеєрного виконання команд

Конвеєрне виконання команд подібне до роботи конвеєра складальної лінії на заводі, наприклад автомобільному. На складальній лінії вироби проходять через однакові виробничі стадії. Одночасно на лінії знаходиться кількість виробів, рівна кількості виробничих стадій. Проходячи через всі виробничі стадії, виріб приймає кінцеві параметри. Час виготовлення одного виробу є рівним часу його проходження через всі виробничі стадії, але при виготовленні багатьох виробів, скажімо n, час, який припадає на виготовлення всіх виробів, є рівним:

Т = tm + t(n - 1) = t(m + n - 1),

де m - кількість виробничих стадій, t - час виконання однієї виробничої стадії, а час, який припадає на виготовлення одного виробу, є рівним:

Тв = t(m + n - 1)/n.

При n >> m час Тв, який припадає на виготовлення одного виробу, наближається до часу t виконання однієї виробничої стадії.

Подібно до виготовлення виробу, команда також має кілька послідовних стадій виконання. Тому логічним виглядає використання і тут принципу конвеєра.

Для початку розглянемо поділ процесу виконання команди на дві стадії: вибірку та виконання. В процесі стадії виконання команди є проміжки часу, коли немає звернень до пам’яті. Цей час може бути використаним для вибірки наступної команди паралельно з виконанням поточної команди. На рис. 18.1 показано цей підхід.

Рисунок 18.1 – Двоярусний конвеєр виконання команди

Конвеєр має два незалежних яруси. Перший ярус виконує операцію вибірки та буферизації (короткотермінового запам’ятовування) команди. Коли другий ярус звільняється від роботи, перший ярус передає йому буферизовану команду. Коли в другому ярусі виконується команда, в першому ярусі вибирається наступна команда. Така операція називається попередньою вибіркою команди (instruction prefetch) або суміщенням вибірки (fetch overlap).

Зрозуміло, що описаний процес прискорює виконання команди. Якби операції вибірки та виконання мали однаковий час виконання, то цикл виконання команди міг би бути зменшеним вдвоє. Однак це не зовсім так через наступні причини:

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

2.   При появі команди умовного переходу адреса наступної команди до завершення поточної команди невідома. Тому перший ярус змушений чекати до завершення роботи другого ярусу. Після цього вже другий ярус повинен чекати на завершення роботи першим ярусом.

Час, який втрачається через другу причину, може бути зменшений шляхом використання механізму передбачення. Тут може бути використане наступне правило: коли команда умовного переходу поступає з ярусу вибірки на ярус виконання, в ярусі вибірки проводиться вибірка із пам’яті наступної команди після команди умовного переходу. Тоді в випадку відсутності умовного переходу втрат часу не буде. Коли ж буде умовний перехід, то вибрана команда повинна бути знехтувана і вибрана нова команда.

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

- Вибірка команди (ВК): зчитування в буфер очікуваної наступною команди.

- Дешифрування команди (ДК): визначення типу вибраної команди та специфікаторів операндів.

- Визначення адрес даних (ВА): обчислення адрес даних, необхідних для виконання команди з врахуванням можливості використання різних способів адресації.

- Вибірка операндів (ВО): зчитування даних із пам’яті в регістри процесора.

- Виконання команди (КВ): виконання вказаної операції та, при наявності, запам’ятовування результату в визначенохму регістрі.

- Запис результату (ЗР): запам’ятовування результату в пам’яті.

При такому поділі час тривалості різних стадій виконання команди буде приблизно рівним. Тоді, як видно з табл. 18.1, шестиярусний конвеєр може зменшити час виконання 9 команд з 54 тактів до 14 тактів.

Таблиця 18.1 – Робота шестиярусного конвеєра

Часова діаграма в табл. 18.1 показує, що кожна команда виконується шляхом проходження через 6 ярусів конвеєра. Разом з тим, не для кожної команди це потрібно. Наприклад, команда вибірки не вимагає виконання операції ЗР. Однак при її виконанні можна зробити шостий ярус конвеєра прозорим

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

Декілька інших факторів обмежують ріст продуктивності за рахунок використання конвеєра:

- неоднаковість часу шести стадій виконання команди приводить до простою деяких з них, як це мало місце в двоярусному конвеєрі;

- поява команди умовного переходу може звести нанівець декілька вибірок команд;

- подібною до команди умовного переходу є команда переривання.

Табл. 18.2 відображає вплив умовного переходу при виконанні тих же операцій, що й в табл. 18.1.

Таблиця  18.2 - Вплив умовного переходу на роботу конвеєра

Тут прийнято, що команда 3 є умовним переходом до команди 15. Поки команда 3 виконується, неможливо взнати, яка команда буде наступною. Конвеєр буде вибирати наступні команди (4, 5, 6, 7) і виконувати їх. Наявність умовного переходу визначиться в кінці сьомого такту. Після цього конвеєр повинен звільнитись від непотрібних команд (очиститись). На 8 такті команда 15 поступить в конвеєр і дальше він почне заповнюватись знову. При цьому від 9 до 12 тактів не буде завершено виконання жодної команди. Це є розплата ефективністю за причини НЕМОЖЛИВОСТІ передбачити перехід.

На рис. 18.1 показано блок-схему виконання команди в шестиярусному конвеєрі з врахуванням переходів та переривань.

Рисунок 18.1 – Шестиярусний конвеєр команд

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

Таким чином, конфлікти конвеєра можуть бути трьох типів:

- Конфлікт ресурсів, наприклад, одночасна потреба доступу до пам’яті. Цей конфлікт вирішується шляхом розділення доступу до ресурсу в часі, або шляхом введення додаткового ресурсу, наприклад, кількох блоків пам’яті.

- Залежність між даними, коли результат виконання деякої команди, яка іще не завершена, є операндом для наступної команди. Для подолання даного конфлікту існує декілька шляхів. Це може бути введення «порожньої» операції nор (яка не виконує дій, але дозволяє ліквідувати конфлікт), введення зв’язків між ярусами конвеєра, що прискорює доступ до потрібного операнда, а також застосування компілятора, здатного передбачати такого типу конфлікти та перевпорядковуваги команди програми.

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

Розглянемо питання підвищення ефективності використання конвеєрної обробки детальніше.

18.2 Запобігання конфліктів у конвеєрі команд

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

Існує три класи конфліктів:

- Структурні конфлікти, які виникають з причини браку ресурсів, коли апаратні засоби не можуть підтримувати всі можливі комбінації команд в режимі одночасного виконання з перекриттям.

- Конфлікти за даними, що виникають у разі, коли виконання наступної команди залежить від результату виконання попередньої команди.

- Конфлікти керування, які виникають при конвеєризації команд передачі керування, які змінюють значення лічильника команд.

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

 18.2.1 Структурні конфлікти

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

Існує дві групи структурних конфліктів. До першої групи належать структурні конфлікти, які виникають через потребу порушення тактової частоти роботи конвеєра. До другої групи належать структурні конфлікти, які виникають у зв’язку з необхідністю очікування на звільнення ресурсів комп’ютера.

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

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

Поява структурних конфліктів першої групи викликає необхідність призупинення роботи конвеєра до закінчення роботи функціонального пристрою, звернення до якого викликало конфлікт. Кількість тактів простою конвеєра рівна відношенню часу виконання операції в функціональному пристрої до величини такту конвеєра. На рис. 18.2 наведено діаграму виконання на симуляторі WinDLX нижче приведеного фрагмента деякої програми:

addf f6, f5, f4

хоr rl, r3, r4

and r5, r6, r7,

у якій виник структурний конфлікт першої групи, викликаний наявністю в програмі команди додавання чисел з плаваючою крапкою addf. Фаза виконання ЕХ цієї команди є довшою в три рази, ніж такт роботи конвеєра. Тому фази МЕМ команд addf та and співпали, тобто вимагається одночасний доступ до ресурсів фази МЕМ, що і стало причиною конфлікту. Через те виконання команди and призупиняється (Stall - зупинка). Час призупинення визначається алгоритмом та структурою пристрою додавання чисел з плаваючою крапкою.

Рисунок 18.2 – Структурний конфлікт першої групи

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

На рис. 18.3 показано приклад такого конфлікту для наступного фрагмента програми:

cvti2f  fl, fl

cvti2f  f2, f2

multf  f5, f4, f8

multf  f6, £3, f4.

Структурний конфлікт виникає на такті - 8, коли відбувається звернення до пристрою множення для виконання фази ЕХ команди multf f6, f3, f4. В цей час пристрій множення зайнятий виконанням фази ЕХ попередньої команди множення, яка триває 5 тактів. Щоб зняти цей конфлікт, потрібно просто призупинити конвеєр на 4 такти, поки відбувається одночасне звернення до пристрою множення (S-stall - структурна зупинка). Подібне призупинення часто називається конвеєрною булькою, оскільки булька проходить по конвеєру, займаючи місце, але не виконуючи ніякої корисної роботи. Потрібно відзначити, що якби множення виконувалось за один такт, структурний конфлікт не виникнув би.

Рисунок 18.3 – Приклад структурного конфлікту при зверненні до пристрою множення

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

Зрозуміло, що комп’ютер, в якому забезпечена підтримка конвеєрного виконання команд без структурних конфліктів, завжди матиме вищу продуктивність порівняно з комп’ютером із структурними конфліктами.

Виникає питання: чому розробники допускають наявність структурних конфліктів? Цьому є дві причини. По-перше, ряд структурних конфліктів принципово дуже важко або й неможливо ліквідувати для всіх випадків роботи конвеєра, наприклад, вирішити питання одночасного доступу до пам’яті даних. По-друге, конвеєризація всіх функціональних пристроїв може виявитися дуже дорогою. Комп’ютери, які допускають два звернення до пам’яті в одному такті, повинні мати пам’ять, яка характеризується подвоєною пропускною спроможністю, наприклад це може бути досягнуто шляхом використання окремих блоків кеш-пам’яті для команд і даних. Аналогічно, повністю конвеєрний пристрій ділення з плаваючою крапкою вимагає значної кількості вентилів. Якщо структурні конфлікти не виникатимуть дуже часто, то не завжди варто платити за те, щоб їх обійти. Тому розробляється скалярний, або не повністю конвеєрний пристрій, що має меншу загальну затримку, ніж повністю конвеєрний. Наприклад, розробники пристроїв з плаваючою крапкою комп’ютерів CDC7600 і MIPS R2010 вважали за краще мати меншу затримку виконання операцій замість повної їх конвеєризації.

 18.2.2 Конфлікти за даними

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

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

Відомі три можливі конфлікти за даними залежно від порядку операцій читання і запису. Розглянемо дві команди - і тa j, при цьому команда і передує команді j. Можливі наступні конфлікти:

1.   WAR (write after read) - читання після запису. Команда j намагається прочитати ще не оновлений командою і операнд (рис. 18.4). Якби не було конвеєра, то спочатку попередня команда і записала б до комірки X операнд, який пізніше був би зчитаний командою j. У випадку використання конвеєрного опрацювання команд, як це видно з рисунка, фаза читання команди j виконується раніше фази запису команди і. Таким чином, команда j може некоректно набути старого значення.

Рисунок 18.4 –  Конфлікт “запис після читання”

2.    RAW (read after write) - запис після читання. Команда j намагається записати операнд до регістра призначення ще до того, як попередній вміст цього регістра прочитає команда і (рис. 18.5). Якби не було конвеєра, то спочатку попередня команда і прочитала б з комірки X операнд, а пізніше до цієї комірки був би записаний інший операнд командою j. У випадку використання конвеєрного опрацювання команд, як це видно з рисунка, фаза запису команди j виконується раніше фази читання команди і. Таким чином, команда і може набути некоректного нового значення.

Рисунок 18.5 – Конфлікт “читання після запису”

3.   WAW (write after write) - запис після запису. Команда j намагається записати операнд до регістра призначення ще до того, як цей запис провела команда і, тобто записи закінчуються в неправильному порядку (рис. 18.6). Якби не було конвеєра, то спочатку попередня команда і записала б до комірки X операнд, а пізніше до цієї комірки був би записаний інший операнд командою j. У випадку використання конвеєрного опрацювання команд, як це видно з рисунка, фаза запису команди j виконується раніше фази запису команди і. В результаті комірка тимчасово отримує некоректний вміст, чим може «скористатися» проміжна k-та команда.

Рисунок 18.6 – Конфлікт “запис після запису”

Можливий також випадок RAR (read after read) - читання після читання, але він небезпеки не створює, і тому не розглядається. Означення, класифікацію та перші методи скасування конфліктів за даними (в оригіналі - data hazards) запропонував Роберт Келлер в 1975 році.

Методи зменшення впливу конфліктів за даними на роботу конвеєра команд

Застосовуються наступні методи зменшення впливу зазначених вище залежностей між даними на роботу конвеєра команд:

• Призупинення виконання команди, тобто затримка з переходом від виконання операції декодування ID до виконання операції виконання ЕХ в конвеєрі доти, доки залежність даних не вичерпується плином часу.

• Випереджувальне пересилання з ярусів конвеєра результатів попередньої команди до потрібного ярусу конвеєра, в якому виконується наступна команда (це потребує додаткових затрат обладнання та ускладнює керування).

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

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

• Перейменування регістрів.

Розглянути названі методи зменшення впливу конфліктів за даними на роботу конвеєра команд детальніше можна у спеціальній літературі.

 18.2.3 Конфлікти керування

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

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

dd r7, r8, rl

bnez г4, $ТЕХТ

and r5, r7, r7

add r2, r2, rЗ

відображена на рис. 18.7, де після декодування команди BNEZ (перехід, якщо не рівний нулю) призупиняється виконання наступної команди.

Рисунок 18.7 – Призупинення конвеєра при виконанні команди умовного переходу

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

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

18.3 Суперконвеєрні процесори

Можлива така організація виконання деякої послідовності команд в процесорі, коли всі однойменні фази виконання цих команди послідовно, тобто спочатку проводиться вибірка всіх команд, далі їх декодування і т. д., як це показано на рис. 18.8  для послідовності із двох команд.

Рисунок 18.8 – Послідовне виконання однойменних фаз двох команд

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

Рисунок 18.9 – Діаграма виконання команди в суперконвеєрному процесорі при послідовному виконанні фаз двох команд

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

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

18.4 Суперскалярні процесори

Вище була розглянута конвеєрна структура процесора, коли засоби виконання ярусів потокового графа алгоритму розділяються конвеєрними регістрами. Щоб підвищити продуктивність конвеєрного процесора потрібно далі спрощувати операції його ярусів та поглиблювати глибину конвеєра. Це і робиться в сучасних процесорах, в яких глибина конвеєра досягає двадцяти і більше ярусів. Наприклад, процесор комп’ютера UltraSPARC III має 10 ярусів конвеєра, а процесор комп’ютера Pentium IV - 20 ярусів конвеєра. Однак процес спрощення операцій ярусів конвеєра має межу, коли операції не піддаються поділу. Наприклад, фаза вибірки команди з пам’яті не може бути поділеною на простіші фази. Тоді для підвищення продуктивності процесора необхідно використовувати паралельне включення декількох конвеєрів команд. Такі процесори з декількома конвеєрами команд дозволяють одночасно виконувати кілька скалярних команд, а тому дістали назву суперскалярних.

Першу суперскалярну архітектуру розробив Джон Коук (John Cocke, IBM, 1987 рік), що отримала назву America. Він і запропонував термін “суперскаляр”. Вже потім модифікований варіант архітектури America під назвою POWER-1 (Performance Optimization With Enhanced RISC) впровадили до серійних систем RISC System/6000 фірми IBM.

Нарешті, підмножину архітектури POWER-1 реалізовано в процесорах Power PC, які є основою комп’ютерів Apple Macintosh. Іншими прикладами суперскалярних процесорів є процесори систем UltraSparc фірми Sun та Alpha фірми DEC.

Структура суперскалярного процесора та його зв’язки з кеш-пам’яттю даних і команд, показані на рис. 18.10.

Рисунок 18.10 – Структура суперскалярного процесора

Тут одночасно вибирається та декодується декілька команд, а блок виконання команд включає кілька функціональних блоків. Для забезпечення одночасного читання та запису кількох операндів кеш-пам’ять будується за модульним принципом.

Зрозуміло, що підвищення продуктивності такого процесора досягається шляхом його конвеєризації. Діаграма виконання команд в суперскалярному процесорі, який має два конвеєри команд, показана на рис. 18.11а.

Рисунок 18.11 – Діаграма виконання команд в суперскалярному процесорі з двома конвеєрами команд, коли в одному такті виконується одна (а) та дві (b) фази команди

Можливе суміщення суперскалярного та суперконвеєрного опрацювання команд, як це показано на рис. 4.16 b.

18.5 Процесор векторного комп’ютера

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

Різницю між виконанням скалярної та векторної операції наглядно відображає рис. 18.12, з якого видно, що скалярна операція передбачає виконання додавання над двома даними, тоді як векторна - над двома векторами даних.

Рисунок 18.12 – Виконання скалярної та векторної операцій додавання

Аби зрозуміти стиль програмування векторних комп’ютерів, наведемо приклад програми із скалярними і векторними кодами. Запишемо програму обчислення виразу Y= а * X + Y, де Y, X - вектори, а а - скаляр. Нехай вектори мають довжину по 64 елементи. Векторна програма має вигляд:

Відповідна скалярна програма має вигляд:

У скалярній програмі курсивом позначено залежності, яких немає у векторному варіанті програми. Обидва варіанти програми можна порівняти за наступними кількісними характеристиками:

1.   За кількістю операцій: 578 (2+9*64) проти 321 (1+5*64); кількість операцій у векторній програмі зменшено в 1,8 рази.

2.   За кількістю команд: 578 (2+9*64) проти 6-ти команд у векторній програмі; перевага в 96 разів.

В таблиці 18.3 наведені характеристики кількох промислових векторних комп’ютерів, з якої видно доцільність їх створення з огляду на досягнуту продуктивність.

Таблиця 18.3 – Характеристики промислових векторних комп’ютерів

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

18.6 Класифікація архітектури комп'ютера за рівнем суміщення опрацювання команд та даних

Виходячи з вищенаведеного розгляду різних принципів побудови процесорів, можна зробити наступну класифікацію архітектури комп’ютера за рівнем суміщення в них опрацювання команд та даних:

- за відсутністю та наявністю конвеєра команд: комп’ютери без конвеєра команд та комп’ютери з конвеєром команд;

- за відсутністю та наявністю конвеєра даних: комп’ютери без конвеєра даних та комп’ютери з конвеєром даних;

- за кількістю послідовно виконуваних фаз команд в конвеєрі: конвеєрні та суперконвеєрні;

- за кількістю одночасно опрацьовуваних даних за однією командою: скалярні та векторні;

- за кількістю одночасно опрацьовуваних скалярних команд: скалярні та суперскалярні;

- за кількістю одночасно опрацьовуваних векторних команд: векторні та супервекторні.

Проведений вище аналіз названих архітектур дозволяє зробити висновок про те, що для побудови високопродуктивних комп’ютерів потрібно, щоб вони мали суперконвеєрну суперскалярну та супервекторну архітектуру.