ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 24.12.2021
Просмотров: 6827
Скачиваний: 22
169
Друга група структурних конфліктів пов'язана з недостатньою кількістю деяких ресурсів (функціональних блоків, портів і т. д.), що перешкоджає виконанню довільної послідовності команд в конвеєрі без його призупинення. Наприклад, процесор може мати тільки один порт запису в регістрову пам'ять, але при певних обставинах конвеєру може виникнути необхідність виконати два записи в регістрову пам'ять в одному такті. Це призводить до структурного конфлікту. Коли послідовність команд натрапляє на такий конфлікт, виконання однієї з команд призупиняється до тих пір, поки не стане доступним необхідний пристрій.
На рис. 5.2 показано приклад такого конфлікту для наступного фрагмента програми:
cvti2f f1, fl
cvti2f f2,f2 multf f5, f4, f8
multf f6,f3,f4.
Структурний конфлікт виникає на такті -8, коли відбувається звернення до пристрою множення для виконання фази ЕХ команди multf f'6,f3,f4. В цей час пристрій множення зайнятий виконанням фази ЕХ попередньої команди множення, яка триває 5 тактів. Щоб зняти цей конфлікт, потрібно просто призупинити конвеєр на 4 такти, поки відбувається одночасне звернення до пристрою множення (S-stall - структурна зупинка). Подібне призупинення часто називається конвеєрною булькою, оскільки булька проходить по конвеєру, займаючи місце, але не виконуючи ніякої корисної роботи. Потрібно відзначити, що якби множення виконувалось за один такт, структурний конфлікт не виникнув би.
Структурні конфлікти другої групи виникають також при одночасному зверненні до пам'яті даних, наприклад, при необхідності читання операнда для однієї команди та запису результату для другої. Такі конфлікти виникають і в комп'ютерах з однією пам'яттю команд і даних. У цьому випадку, коли одна команда, яка знаходиться в конвеєрі, здійснює звернення до пам'яті за даними, воно конфліктуватиме з вибіркою пізнішої в черзі команди, яка вибирається з тієї ж пам'яті. В комп'ютері DLX можливий конфлікт, наприклад, при одночасному зверненні до основної пам'яті з боку кеш пам'яті даних та
команд.
Зрозуміло, що комп'ютер, в якому забезпечена підтримка конвеєрного виконання команд без структурних конфліктів, завжди матиме вищу продуктивність порівняно з комп'ютером із структурними конфліктами. Виникає питання: чому розробники допускають наявність структурних конфліктів? Цьому є дві причини. По-перше, ряд структурних конфліктів принципово дуже важко або й неможливо ліквідувати для всіх ви-падківроботи конвеєра, наприклад, вирішити питання одночасного доступу до пам'яті
170
даних. По-друге, конвеєризація всіх функціональних пристроїв може виявитися дуже дорогою. Комп'ютери, які допускають два звернення до пам'яті в одному такті, повинні мати пам'ять, яка характеризується подвоєною пропускною спроможністю, наприклад, це може бути досягнуто шляхом використання окремих блоків кеш пам'яті для команд і даних. Аналогічно, повністю конвеєрний пристрій ділення з рухомою комою вимагає значної кількості вентилів. Якщо структурні конфлікти не виникатимуть дуже часто, то не завжди варто платити за те, щоб їх обійти. Тому розробляється скалярний, або не повністю конвеєрний пристрій, що має меншу загальну затримку, ніж повністю конвеєрний. Наприклад, розробники пристроїв з рухомою комою комп'ютерів CDC7600 і MIPS R2010 вважали за краще мати меншу затримку виконання операцій замість повної їх конвеєризації.
5.2. Конфлікти за даними
5.2.1. Типи конфліктів за даними
Одним з чинників, який істотно впливає на продуктивність конвеєрних комп'ютерів, є логічні залежності між командами. Такі залежності великою мірою обмежують потенційний паралелізм суміжних операцій виконання команд, що забезпечується відповідними апаратними засобами. Ступінь впливу цих залежностей визначається як структурою комп'ютера (в основному, організацією керування конвеєром команд і характеристиками функціональних пристроїв), так і характеристиками програм.
Конфлікт за даними виникає при наявності залежності між командами, коли вони розташовані в програмі близько одна до одної. В цьому випадку для забезпечення перекриття виконання операцій залежних команд може виникнути необхідність у зміні порядку звернення за операндами.
Відомі три можливі конфлікти за даними залежно від порядку операцій читання і запису. Розглянемо дві команди - і та j, при цьому команда і передує команді j. Можливі наступні конфлікти:
2. RAW (read after write) - запис після читання. Команда j намагається записати операнд до регістра призначення ще до того, як попередній вміст цього регістра прочитає команда і (рис. 5.4). Якби не було конвеєра, то спочатку попередня команда і прочитала
1. WAR (write after read) - читання після запису. Команда j намагається прочитати ще не оновлений командою і операнд (рис. 5.3). Якби не було конвеєра, то спочатку попередня команда і записала б до комірки X операнд, який пізніше був би зчитаний командою). У випадку використання конвеєрного опрацювання команд, як це видно з рисунка, фаза читання команди j виконується раніше фази запису команди і. Таким чином, команда j може некоректно набути старого значення.
171
б з комірки X операнд, а пізніше до цієї комірки був би записаний інший операнд командою j. У випадку використання конвеєрного опрацювання команд, як це видно з рисунка, фаза запису команди j виконується раніше фази читання команди і. Таким чином, команда і може набути некоректного нового значення.
3. WAW
(write after write) - запис після
запису. Команда j
намагається записати опе-ранд
до регістра призначення ще до того, як
цей запис провела команда і, тобто
записи закінчуються в неправильному
порядку (рис. 5.5). Якби не було конвеєра,
то спочатку попередня команда і записала
б до комірки X операнд,
а пізніше до цієї комірки був би записаний
інший операнд командою j.
У випадку використання
конвеєрного опрацювання команд, як
це видно з рисунка, фаза запису команди
j виконується
раніше фази запису команди і. В результаті
комірка тимчасово отримує некоректний
вміст, чим може «скористатися» проміжна
k-та команда.
Можливий також випадок RAR (read after read) - читання після читання, але він небезпеки не створює, і тому не розглядається. Означення, класифікацію та перші методи скасування конфліктів за даними (в оригіналі - data hazards) запропонував Роберт Кел-лер в 1975 році.
5.2.2. Методи зменшення впливу конфліктів за даними на роботу конвеєра команд
Застосовуються наступні методи зменшення впливу зазначених вище залежностей між даними на роботу конвеєра команд:
■ Призупинення виконання
команди, тобто затримка з переходом
від виконання
операції декодування
ID до
виконання операції виконання ЕХ в
конвеєрі доти, доки за
лежність
даних не вичерпується плином часу.
■ Випереджувальне пересилання з ярусів
конвеєра результатів попередньої
коман
ди до потрібного ярусу
конвеєра, в якому виконується наступна
команда (це потребує
додаткових
затрат обладнання та ускладнює
керування).
" Статична диспетчеризація послідовності команд у програмі під час компіляції з метою зменшення впливу конфліктів за даними на роботу конвеєра команд шляхом зміни порядку виконання залежних одна від одної команд.
1 72
-
Динамічна диспетчеризація послідовності команд у програмі під час компіляції з тією ж, що й статична диспетчеризація, метою.
-
Перейменування регістрів.
Розглянемо далі названі методи зменшення впливу конфліктів за даними на роботу конвеєра команд детальніше.
5.2.3. Призупинення виконання команди
Найпростішим рішенням для зменшення впливу конфліктів на роботу конвеєра команд при наявності залежності між даними є призупинення виконання команди j на декілька тактів з тим, щоб завершилось виконання команди і, або тієї її фази, яка викликала конфлікт. Відповідно затримається і виконання команд, які йдуть слідом за командою і.
Розглянемо фрагмент програми, виконання якого вимагає призупинення роботи конвеєра:
LW R1,0(R2)
SUB R4,R1,R5
AND R6,R1,R7
OR R8,R1,R9
Рис. 5.6 ілюструє роботу конвеєра при виконанні поданого вище фрагмента програми.
Тут друга команда SUB потребує результату виконання першої команди, який з'являється лише на такті 12 (фаза MEM), через що виконання призупиняється (зупинка R-Stall) до завершення вказаного такту. Призупинення конвеєра знижує його ефективність, тому частіше використовують інші шляхи ліквідації впливу залежностей між даними.
5.2,4. Випереджувальне пересилання
Найпоширенішим способом запобігання конфліктам в конвеєрі команд, поява яких викликана залежностями між даними, є випереджувальне пересилання даних із попередніх ярусів конвеєра в яруси, де ці дані потрібні, минаючи проміжні яруси конвеєра. Розглянемо застосування випереджувального пересилання на кількох прикладах для конкретних фрагментів коду програми.
Випереджувальне пересилання даних з метою усунення конфлікту і пригальмовування конвеєра комп'ютера DLX для коду програми
173
SUB R5,R6,R7 LW R4,0(R5) SW 12(R5),R6
ілюструє рис. 5.7, на якому показано результат виконання приведеної програми на симуляторі комп'ютера DLX WinDLX. Залежність за даними виникає за рахунок використання другою командою вмісту регістра R5 за умови, що цей вміст оновлюється попередньою (першою) командою фрагмента. Цю залежність долають шляхом випереджувального пересилання результату першої команди (що використовується потім як зсувний компонент адреси) з інтегрованого (до конвеєрного регістра) поля ALUoutput (на такті -7) на вхід ALU (на такті -6). На рисунку це позначено похилою додатковою лінією. Випереджувальне пересилання грунтується на тому, що реально зсувна компонента формується вчасно, вона вже існує в надрах конвеєра, але не є ще занесеною до регістра регістрового файла (для цього треба виконати ще фази MEM і WB).
Випереджувального пересилання вимагає і остання (третя) команда через те, що використовує вміст регістра R4, який формується другою командою. Третій команді потрібно ще одне випереджувальне пересилання зсувної компоненти виконавчої адреси (вмісту регістра R5), що позначено на рисунку іще однією додатковою лінією.
Потрібно зазначити, що випереджувальне пересилання не завжди є можливим. Розглянемо виконання в конвеєрі наступного фрагмента коду
LW R1,0(R2)
ADD R4,Rl,R2
AND R6,R1,R7
XOR R3,R1,R5.
Залежність даних обумовлена використанням командами, які надходять після першої команди, вмісту регістра R1, який у конвеєрі формується із стандартною затримкою. При цьому друга команда використовує випереджувальне пересилання даних від першої команди після завершення фази MEM, коли вже отримано майбутній вміст регістра R1. Але оскільки цей вміст отримано лише на такті -6, а він був потрібний на такті -7, то з'явилась затримка R-Stall, тому, що принципово неможливе пересилання до минулого (рис. 5.8).