Основи організації обчислювальних систем Процесори Архітектура системи команд. Класифікація процесорів (CISC і RISC)

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

Двома основними архитектурами набору команд, що використовуються комп'ютерної промисловістю на сучасному етапі розвитку обчислювальної техніки є
архітектури CISC і RISC. Основоположником CISC-архітектури можна вважати
компанію IBM з її базової архітектурою/360, ядро якої використовується з 1964
року і дійшла до наших днів, наприклад, у таких сучасних мейнфреймах як IBM ES/9000.

Лідером у розробці мікропроцесорів c повним набором команд (CISC - Complete Instruction Set Computer) вважається компанія Intel зі своєю серією x86 і Pentium. Ця архітектура є практичним стандартом для ринку мікрокомп'ютерів. Для CISC-процесорів характерно: порівняно невелике число регістрів загального призначення; велика кількість машинних команд, деякі з яких навантажені семантично аналогічно операторам високорівневих мов програмування і виконуються за багато тактів; велика кількість методів адресації; велику кількість форматів команд різної розрядності; переважання двоадресного формату команд; наявність команд обробки типу регістр-пам'ять.

Основою архітектури сучасних робочих станцій і серверів є архітектура комп'ютера зі скороченим набором команд (RISC - Reduced Instruction Set Computer). Зародки цієї архітектури йдуть своїм корінням до комп'ютерів CDC6600, розробники яких (Торнтон, Крей та ін) усвідомили важливість спрощення набору команд для побудови швидких обчислювальних машин. Цю традицію спрощення архітектури С. Крей з успіхом застосував при створенні широко відомої серії суперкомп'ютерів компанії Cray Research. Проте остаточно поняття RISC в сучасному його розумінні сформувався на базі трьох дослідних проектів комп'ютерів: процесора 801 компанії IBM, процесора RISC університету Берклі і процесора MIPS Стенфордського університету.

Розробка експериментального проекту компанії IBM почалася ще в кінці 70-х років, але його результати ніколи не публікувалися і комп'ютер на його основі в промислових масштабах не виготовлявся. У 1980 році Д. Паттерсон зі своїми колегами з Берклі почали свій проект і виготовили дві машини, які отримали назви RISC-I і RISC-II. Головними ідеями цих машин було відділення повільної пам'яті від високошвидкісних регістрів і використання реєстрових вікон. У 1981 році Дж. Хеннессі зі своїми колегами опублікував опис Стенфордському машини MIPS, основним аспектом розробки якої була ефективна реалізація конвеєрної обробки за допомогою ретельного планування компілятором його завантаження.

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

Серед інших особливостей RISC-архітектур слід відзначити наявність досить великого реєстрового файлу (в типових RISC-процесорах реалізуються 32 або більше з регістрів у порівнянні з 8 - 16 регістрами в CISC-архітектур), що дозволяє більшого обсягу даних зберігатися в регістрах на процесорному кристалі більший час і спрощує роботу компілятора з розподілу регістрів під змінні. Для обробки, як правило, використовуються трехадресние команди, що крім спрощення дешифрації дає можливість зберігати більше число змінних в регістрах без їх подальшої перезавантаження.

До часу завершення університетських проектів (1983-1984 рр.). позначився також прорив в технології виготовлення надвеликих інтегральних схем. Простота архітектури та її ефективність, підтверджена цими проектами, викликали великий інтерес у комп'ютерної індустрії і з 1986 року почалася активна промислова реалізація архітектури RISC. До теперішнього часу ця архітектура міцно займає лідируючі позиції на світовому комп'ютерному ринку робочих станцій і серверів.

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

Слід зазначити, що в останні розробки компанії Intel (маються на увазі Pentium і Pentium Pro), а також її послідовників-конкурентів (AMD R5, Cyrix M1, NexGen Nx586 тощо) широко використовуються ідеї, реалізовані в RISC-мікропроцесори, так що багато розходжень між CISC і RISC стираються. Однак складність архітектури та системи команд x86 залишається і є головним чинником, що обмежує продуктивність процесорів на її основі. Конвеєрна організація Найпростіша організація конвеєра і оцінка його продуктивності

Розробники архітектури комп'ютерів здавна вдавалися до методів проектування, відомим під загальною назвою "поєднання операцій", при якому апаратура комп'ютера в будь-який момент часу виконує одночасно більше однієї базової операції. Цей загальний метод містить два поняття: паралелізм і конвейеризації. Хоча в них багато спільного і їх найчастіше важко розрізняти на практиці, ці терміни відображають два абсолютно різні підходи. При паралелізм суміщення операцій досягається шляхом відтворення в декількох копіях апаратної структури. Висока продуктивність досягається за рахунок одночасної роботи всіх елементів структур, що здійснюють вирішення різних частин завдання.

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

Для ілюстрації основних принципів побудови процесорів ми будемо використовувати просту архітектуру, що містить 32 цілочисельних регістра загального призначення (R0, ..., R31), 32 регістри плаваючої крапки (F0 ,..., F31) і лічильник команд PC. Будемо
вважати, що набір команд нашого процесора включає типові
арифметичні і логічні операції, операції з плаваючою точкою, операції пересилання даних, операції керування потоком команд і системні операції. В арифметичних
командах використовується трехадресний формат, типовий для RISC-процесорів, а для звернення до пам'яті використовуються операції завантаження і запису вмісту регістрів на згадку.

Виконання типової команди можна розділити на наступні етапи:  вибірка команди - IF (за адресою, заданому лічильником команд, з      пам'яті витягується команда);  декодування команди/вибірка операндів із регістрів - ID;  виконання операції/обчислення ефективної адреси пам'яті - EX;  звернення до пам'яті - MEM;  запам'ятовування результату - WB.

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

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

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

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

Рис. 3.1. Схема неконвейерного цілочисельного пристрої         Номер команди          Номер такту           1          2          3          45 6 7 8 9             Команда i         IF         ID         EX         MEMWB                Команда i +1      IF         ID         EXMEM WB                Команда i +2      IF         IDEX MEM WB                Команда i +3      IFID EX MEM WB                Команда i +4      IF ID EX MEM WB    

Рис. 3.2. Діаграма роботи найпростішого конвеєра

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

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

Суміщений режим виконання команд в загальному випадку вимагає конвейеризації
функціональних пристроїв і дублювання ресурсів для розв'язання всіх можливих комбінацій команд в конвеєрі. Якщо яка-небудь комбінація команд не може
бути прийнята з-за конфлікту по ресурсах, то говорять, що в машині є структурний конфлікт. Найбільш типовим прикладом машин, у яких можливе поява структурних конфліктів, є машини з не повністю конвеєрними функціональними пристроями. Час роботи такого пристрою може складати кілька тактів синхронізації конвеєра. У цьому випадку послідовні команди,
які використовують даний функціональний пристрій, не можуть вступати до нього в кожному такті. Інша можливість появи структурних конфліктів пов'язана з
недостатнім дублюванням деяких ресурсів, що перешкоджає виконанню
довільній послідовності команд в конвеєрі без його призупинення. Наприклад, машина може мати тільки один порт записи в регістровий файл, але при певних обставин конвеєру може бути потрібно виконати два записи в регістровий файл в одному такті. Це також призведе до структурної конфлікту. Коли
послідовність команд наштовхується на такий конфлікт, конвеєр призупиняє виконання однієї з команд до тих пір, поки не стане доступним потрібне
пристрій.

Структурні конфлікти виникають, наприклад, і в машинах, в яких є єдиний конвеєр пам'яті для команд і даних (малюнок 3.3). У цьому випадку, коли одна команда містить звернення до пам'яті за даними, воно буде конфліктувати з вибіркою пізнішої команди з пам'яті. Щоб вирішити цю ситуацію, можна просто припинити конвеєр на один такт, коли відбувається звернення до пам'яті за даними. Подібна припинення часто називаються "конвеєрним бульбашкою" (pipeline bubble) або просто міхуром, оскільки міхур проходить по конвеєру, займаючи місце, але не виконуючи ніякої корисної роботи.         Команда          Номер такту           1          2          3          45 6 7 8 9 10             Команда завантаження         IF         ID         EX         MEMWB                Команда 1      IF         ID         EXMEM WB                Команда 2      IF         IDEX MEM WB                Команда 3      stallIF ID EX MEM WB                Команда 4         IF ID EX MEM WB             Команда 5         IF ID EX MEM             Команда 6         IF ID EX     

Рис. 3.3. Діаграма роботи конвеєра при структурному конфлікті

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

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

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

У цьому прикладі всі команди, що слідують за командою ADD, використовують результат її виконання. Команда ADD записує результат в регістр R1, а команда SUB читає це значення. Якщо не вжити жодних заходів для того, щоб запобігти цей конфлікт, команда SUB прочитає неправильне значення і спробує його використовувати. Насправді значення, яке використовується командою SUB, є навіть невизначеним: хоча логічно припустити, що SUB завжди буде використовувати значення R1, яке було присвоєно будь-якої командою, яка відбулася перед ADD, це не завжди так. Якщо відбудеться переривання між командами ADD і SUB, то команда ADD завершиться, і значення R1 в цій точці буде відповідати результату ADD. Таке непрогнозоване поведінка очевидно неприйнятно.        ADD         R1, R2, R3      IF         ID         EXMEM WB                                     SUB         R4, R1, R5      IF         IDEX MEM WB                                AND         R6, R1, R7      IFID EX MEM WB                                OR         R8, R1, R9      IF ID EX MEM WB                                XOR         R10, R1, R11         IF ID EX MEM WB     

Рис. 3.4. Послідовність команд в конвеєрі і прискорена пересилання даних
(data forwarding, data bypassing, short circuiting)

Проблема, поставлена в цьому прикладі, може бути вирішена за допомогою досить простої апаратної техніки, яка називається пересиланням або просуванням даних (data forwarding), обходом (data bypassing), іноді закороткому (short-circuiting). Ця апаратура працює таким чином. Результат операції АЛП з його вихідного регістра завжди знову подається тому на входи АЛП. Якщо апаратура виявляє, що попередня операція АЛУ записує результат до реєстру, відповідний джерела операнда для наступної операції АЛП, то логічні схеми управління вибирають як входу для АЛУ результат, який надходить по ланцюгу "обходу", а не значення, прочитане з реєстрового файлу.

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

Конфлікти за даними, що призводять до припинення конвеєра

На жаль не всі потенційні конфлікти за даними можуть оброблятися за допомогою механізму "обходів". Розглянемо наступну послідовність команд (рисунок 3.5):        Команда                      LW R1, 32 (R6)      IF         ID         EXMEM WB                ADD R4, R1, R7      IF         IDstall EX MEM WB                SUB R5, R1, R8      IF stall ID EX MEM WB                AND R6, R1, R7      stall IF ID EX MEM WB    

Рис. 3.5. Послідовність команд з призупиненням конвеєра

Цей випадок відрізняється від послідовності поспіль команд АЛП. Команда завантаження (LW) регістра R1 з пам'яті має затримку, яка не може бути усунена звичайної "пересиланням". Замість цього нам потрібна додаткова апаратура, яка називається апаратурою внутрішніх блокувань конвеєра (pipeline interlook), щоб забезпечити коректне виконання прикладу. Взагалі такого роду апаратура виявляє конфлікти і призупиняє конвеєр до тих пір, поки існує конфлікт. У цьому випадку ця апаратура призупиняє конвеєр починаючи з команди, яка хоче використати дані в той час, коли попередня команда, результат якої є операндом для нашої, виробляє цей результат. Ця апаратура викликає призупинення конвеєра або появу "бульбашки" точно також, як і у випадку структурних конфліктів.

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

Багато типів пріостановок конвеєра можуть відбуватися досить часто. Наприклад, для оператора А = B + С компілятор швидше за все згенерує наступну послідовність команд (рисунок 3.6):        LW R1, В         IF         ID         EX         MEMWB                LW R2, С      IF         ID         EXMEM WB                ADD R3, R1, R2      IF         IDstall EX MEM WB                SW A, R3      IF stall ID EX MEM WB     

Рис. 3.6. Конвеєрне виконання оператора А = В + С

Очевидно, виконання команди ADD повинно бути припинено до тих пір, поки не стане доступним надходить з пам'яті операнд C. Додатковою затримки виконання команди SW не відбудеться у разі застосування ланцюгів обходу для пересилання результату операції АЛУ безпосередньо в регістр даних пам'яті для подальшого запису.

Для цього простого прикладу компілятор ніяк не може покращити ситуацію, проте в ряді більш загальних випадків він може реорганізувати послідовність команд так, щоб уникнути пріостановок конвеєра. Ця техніка, яка називається плануванням завантаження конвеєра (pipeline scheduling) або плануванням потоку команд (instruction scheduling), використовувалася починаючи з 60-х років і стала особливою областю інтересу в 80-х роках, коли конвеєрні машини стали більше поширеними.

Нехай, наприклад, є послідовність операторів: a = b + c; d = e - f;

Як згенерувати код, що не викликає зупинок конвеєра? Передбачається, що затримка завантаження з пам'яті становить один такт. Відповідь очевидна (малюнок 3.7):         неоптимізованих
послідовність команд          Оптимізована
послідовність команд             LW Rb, b         LW Rb, b             LW Rc, c         LW Rc, c             ADD Ra, Rb, Rc         LW Re, e             SW a, Ra         ADD Ra, Rb, Rc             LW Re, e         LW Rf, f             LW Rf, f         SW a, Ra             SUB Rd, Re, Rf         SUB Rd, Re, Rf             SW d, Rd         SW d, Rd     

Рис. 3.7. Приклад усунення конфліктів компілятором

У результаті усунені обидві блокування (командою LW Rc, c команди ADD Ra, Rb, Rc і командою LW Rf, f команди SUB Rd, Re, Rf). Є залежність між операцією АЛУ і операцією запису в пам'ять, але структура конвеєра допускає пересилання результату за допомогою ланцюгів "обходу". Зауважимо, що використання різних регістрів для першого і другого операторів було достатньо важливим для реалізації такого правильного планування. Зокрема, якщо мінлива e була б завантажена в той же самий регістр, що b або c, таке планування не було б коректним. У загальному випадку планування конвеєра може вимагати збільшення кількості регістрів. Таке збільшення може виявитися особливо суттєвим для машин, які можуть видавати на виконання декілька команд в одному такті.

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

На щастя, існують апаратні методи, що дозволяють змінити порядок виконання команд програми так, щоб мінімізувати припинення конвеєра. Ці методи отримали загальну назву методів динамічної оптимізації (в англомовній літературі останнім часом часто застосовуються також терміни "out-of-order execution" - невпорядковане виконання і "out-of-order issue" - неупорядкована видача). Основними засобами динамічної оптимізації є:  Розміщення схеми виявлення конфліктів в якомога більш низькою      точці конвеєра команд так, щоб дозволити команді просуватися по      конвеєру до тих пір, поки їй реально не буде потрібно операнд, що є      також результатом логічно більш ранньої, але ще не завершилася команди.      Альтернативним підходом є централізоване виявлення конфліктів      на одній з ранніх ступенів конвеєра.  Буферизація команд, які чекають вирішення конфлікту, і видача      наступних, логічно не пов'язаних команд, в "обхід" буфера. У      цьому випадку команди можуть видаватися на виконання не в тому порядку, в      якому вони розташовані в програмі, проте апаратура виявлення і      усунення конфліктів між логічно пов'язаними командами забезпечує      отримання результатів відповідно до заданої програми.  Відповідна організація комутуючих магістралей,      забезпечує засилання результату операції безпосередньо в буфер,      зберігає логічно залежну команду, затриману через конфлікт, або      безпосередньо на вхід функціонального пристрою до того, як цей      результат буде записаний в регістровий файл або в пам'ять (short-circuiting,      data forwarding, data bypassing - методи, які були розглянуті раніше).      

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

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

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

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

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

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

Найпростіший метод роботи з умовними переходами полягає в припиненні конвеєра як тільки виявлена команда умовного переходу до тих пір, поки вона не досягне ступені конвеєра, яка обчислює нове значення лічильника команд (рисунок 3.8). Такі призупинення конвеєра через конфлікти з управління повинні реалізовуватися інакше, ніж призупинення через конфлікти за даними, оскільки вибірка команди, наступної за командою умовного переходу, повинна бути виконана як можна швидше, як тільки ми дізнаємося остаточне напрямок команди умовного переходу.        Команда переходу         IF         ID         EX         MEMWB                Наступна команда      IF         stall         stallIF ID EX MEM WB                Наступна команда 1      stall         stallstall IF ID EX MEM WB             Наступна команда 2      stallstall stall IF ID EX MEM             Наступна команда 3      stall stall stall IF ID EX          Наступна команда 4         stall stall stall IF ID             Наступна команда 5         stall stall stall IF     

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

Наприклад, якщо конвеєр буде припинено на три такти на кожній команді умовного переходу, то це може істотно впливати на продуктивність машини. При частоті команд умовного переходу в програмах, що дорівнює 30% і ідеальному CPI, рівним 1, машина з призупиненням умовних переходів сягає приблизно лише половини прискорення, що отримується за рахунок конвеєрної організації. Таким чином, зниження втрат від умовних переходів стає критичним питанням. Число тактів, втрачається при призупинення через умовних переходів, може бути зменшено двома способами:  Виявленням чи є умовний перехід виконуваних або      невиполняемим на більш ранніх ступенях конвеєра.  Більш раннім обчисленням значення лічильника команд для виконуваного      переходу (тобто обчисленням цільового адреси переходу).

Зниження втрат на виконання команд умовного переходу

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

Метод вичікування

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

Метод повернення

Більш добра і не на багато більш складна схема полягає в тому, щоб прогнозувати умовний перехід як невиполняемий. При цьомуапаратура повинна просто продовжувати виконання програми, як якби умовний перехід зовсім не виконувався. У цьому випадку необхідно подбати про те, щоб не змінити стан машини до тих пір, поки напрямок переходу не стане остаточно відомим. У деяких машинах ця схема з невиполняемимі за прогнозом умовними переходами реалізована шляхом продовження вибірки команд, як якби умовний перехід був звичайною командою. Поведінка конвеєра виглядає так, ніби нічого незвичайного не відбувається. Однак, якщо умовний перехід насправді виконується, то необхідно просто очистити конвеєр від команд, вибраних слідом за командою умовного переходу і знову повторити вибірку команд (рисунок 3.9).        Невиполняемий умовний перехід         IF         IDEX MEM WB                Команда i +1      IFID EX MEM WB                Команда i +2      IF ID EX MEM WB                Команда i +3      IF ID EX MEM WB                Команда i +4      IF ID EX MEM WB                          Виконуваний
умовний перехід         IF         IDEX MEM WB                Команда i 1/цільова команда      IFIF ID EX MEM WB                Цільова команда 1      stall IF ID EX MEM WB                Цільова команда 2      stall IF ID EX MEM WB             Цільова команда 3      stall IF ID EX MEM     

Рис. 3.9. Діаграма роботи модернізованого конвеєра

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

Затримані переходи

Четверта схема, яка використовується в деяких машинах називається "затриманим переходом". У затриманого переході такт виконання з затримкою переходу довжиною n є:

команда умовного переходу

наступна команда 1

наступна команда 2

.....

наступна команда n

цільової адресу при виконуваному переході

Команди 1 - n перебувають у слотах (тимчасових інтервалах) затриманого переходу. Завдання програмного забезпечення полягає в тому, щоб зробити команди, що слідують за командою переходу, дійсними та корисними. Апаратура гарантує реальне виконання цих команд перед виконанням влас