4. Підтримка точних переривань

Інша проблема, пов'язана з реалізацією команд із більшим часом виконання, може бути проілюстрована за допомогою наступної послідовності команд:

DIVF F0,F2,F4

ADDF F10,F10,F8

SUBF F12,F12,F14

Ця послідовність команд виглядає дуже просто. У ній відсутні які-небудь залежності. Однак вона приводить до появи нових проблем через те, що видана раніше команда може завершитися після команди, виданої для виконання пізніше. У даному прикладі можна чекати, що команди ADDF і SUBF завершуватися раніше, ніж завершиться команда DIVF. Цей ефект є типовим для конвеєрів команд із більшим часом виконання й називається позачерговим завершенням команд (out-of-order completion). Тоді, наприклад, якщо команда DIVF викличе арифметичне переривання після завершення команди ADDF, ми не зможемо реалізувати точне переривання на рівні апаратур. У дійсності, оскільки команда ADDF міняє значення одного зі своїх операндів, неможливо навіть за допомогою програмних засобів відновити стан, що було перед виконанням команди DIVF.

Є чотири можливих підходи для роботи в умовах позачергового завершення команд. Перший з них просто ігнорує проблему й пропонує механізми неточного переривання. Цей підхід використовувався в 60-х і 70-х роках і усе ще застосовується в деяких суперкомп'ютерах, у яких деякі класи переривань заборонені або обробляються апаратурами без зупинки конвеєра. Такий підхід важко використати в сучасних машинах при наявності концепції віртуальної пам'яті й стандарту на операції із плаваючою крапкою IEEE, які вимагають реалізації точного переривання шляхом комбінації апаратних і програмних засобів. У деяких машинах ця проблема вирішується шляхом введення двох режимів виконання команд: швидкого, але з можливо не точними перериваннями, і повільну, гарантуючу реалізацію точних переривань.

Другий підхід полягає в буферизації результатів операції до моменту завершення виконання всіх команд, що передували даній. У деяких машинах використовується цей підхід, але він стає усе більш дорогим, якщо відмінності в часі виконання різних команд великі, оскільки стає більшим кількість результатів, які необхідно буферизувати. Більше того, результати із цієї буферизованої черги необхідно пересилати для забезпечення продовження видачі нових команд. Це вимагає великої кількості схем порівняння й багатовходових мультиплексорів. Є дві варіації цього основного підходу. Перша називається буфером історії (history file), що использовались у машині CYBER 180/990. Буфер історії відслідковує первісні значення регістрів. Якщо виникає переривання й стан машини необхідно відкотити назад до крапки, що передувала деяким командам, що завершилися позачергово, то первісне значення регістрів може бути відновлене із цього буфера історії. Подібна методика використовувалася також при реалізації автоінкрементної і автодекрементної адресації в машинах типу VAX. Інший підхід називається буфером майбутнього (future file). Цей буфер зберігає нові значення регістрів. Коли всі попередні команди завершені, основний регістровий файл поновлюється значеннями із цього буфера. При перериванні основний регістровий файл зберігає точні значення регістрів, що спрощує організацію переривання. У наступній главі будуть розглянуті деякі розширення цієї ідеї.

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

Команда 1 - довга команда, що зрештою викликає переривання

Команда 2, ... , Команда n-1 - послідовність команд, виконання яких не завершилося

Команда n - команда, виконання якої завершилося

Маючи значення адрес всіх команд у конвеєрі та адреса повернення з переривання, програмне забезпечення може визначити стан команди 1 і команди n. Оскільки команда n завершила виконання, хотілося б продовжити виконання з команди n+1. Після обробки переривання програмне забезпечення повинне змоделювати виконання команд із 1 по n-1. Тоді можна здійснити повернення з переривання на команду n+1. Найбільша неприємність такого підходу пов'язана з ускладненням підпрограми обробки переривання. Але для простих конвеєрів, подібних розглянутому нами, є й спрощення. Якщо команди з 2 по n усі є цілочисельними, то ми просто знаємо, що у випадку завершення виконання команди n, всі команди з 2 по n-1 також завершили виконання. Таким чином, необхідно обробляти тільки операцію із плаваючою крапкою. Щоб зробити цю схему працюючою, кількість операцій ПК, що виконуються зі сполученням, може бути обмежена. Наприклад, якщо допускається сполучення тільки двох операцій, те тільки перервана команда повинна завершуватися програмними засобами. Це обмеження може знизити потенційну пропускну здатність, якщо конвеєри плаваючої крапки є досить довгими або якщо є значна кількість функціональних пристроїв. Такий підхід використовувався в архітектурі SPARC, що дозволяє сполучати виконання цілочисельними операцій з операціями плаваючої крапки.

Четвертий метод являє собою гібридну схему, що дозволяє продовжувати видачу команд тільки якщо відомо, що всі команди, що передували видаванємій, будуть завершені без переривання. Це гарантує, що у випадку виникнення переривання жодна наступна за нею команда не буде завершена, а всі попередні будуть завершені. Іноді це означає необхідність припинення машини для підтримки точних переривань. Щоб ця схема працювала, необхідно, щоб функціональні пристрої плаваючої крапки визначали можливість появи переривання на самій ранній стадії виконання команд так, щоб запобігти завершенню виконання наступних команд. Така схема використовується, наприклад, у мікропроцесорах R2000/R3000 і R4000 компанії MIPS.