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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

В архітектурі комп'ютера, перейменування регістрів (англ. Register Renaming) — це метод ослаблення взаємозалежностей команд, що виконуються процесором, при позачерговому виконанні.

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

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

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

Визначення проблеми[ред.ред. код]

У регістрової машині програми складаються з команд, які працюють на певних значеннях. Команди повинні називати ці значення для того, щоб їх можна було відрізнити один від одного. Звичайна команда повинна сказати, додати X, додати Y і результат записати в Z. В командах є X, Y і Z і імена місць зберігання. Щоб мати компактний код команд, більшість наборів команд процесора мають невеликий набір в спеціальних місцях, які можуть бути безпосередньо названі. Наприклад, набір команд для x86 архітектури мають 8 цілих регістрів, x86-64 мають 16, багато RISCs мають 32, а IA-64 - 128. У невеликих процесорах ім'я цієї області пам'яті відповідають елементам регістрового файлу. Різні команди можуть займати різну кількість часу; наприклад процесор здатний виконувати сотні команд, поки навантажена основна область пам'яті. Більш короткі команди виконуються, поки майбутня навантаження закінчить перше, тому команди закінчують роботу з оригінальної програми. Через порядку виконання вони використовується в самих останніх високопродуктивних процесорах для досягнення невеликого збільшення швидкості. Розглянемо, як цей шматок коду працює поза порядком процесора:

# Команди
1 R1 = M[1024]
2 R1 = R1 + 2
3 M[1032] = R1
4 R1 = M[2048]
5 R1 = R1 + 4
6 M[2056] = R1

Команди 4, 5 і 6 є незалежними командами 1, 2 і 3, але процесор не може завершити 4 до тих пір, поки 3 не буде зроблено, в іншому випадку в 3 команди буде записано некоректне значення. Ці обмеження можуть бути усунені шляхом зміни імен деяких регістрів:

# Команда # Команда
1 R1 = M[1024] 4 R2 = M[2048]
2 R1 = R1 + 2 5 R2 = R2 + 4
3 M[1032] = R1 6 M[2056] = R2

Зараз команди 4,5 і 6 можуть виконуватися паралельно 1, 2 і 3, так що програма може виконувати свою роботу швидше. Компілятор виявив різні команди і спробував призначити їх на інший регістр, коли це було можливо. Тим не менш, існує кінцеве число імен регістру які можуть бути використані в кінцевому коді. Багато високопродуктивні процесори можуть мати більше фізичних регістрів, ніж може бути названо безпосередньо в наборі команд, так що вони перейменовують регістри в апаратному забезпеченні, щоб досягти додаткового паралелізму.

Небезпека даних[ред.ред. код]

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

Читання після запису (RAW)
При читанні з регістра або комірки пам'яті, повинно повернути значення вміщеній там останнього запису в програмному порядку, не якимось іншим записаним. Це згадується як істинність справи або потоку справ, і вимагає вказівки для виконання з метою програми.
Запис після запису (WAW)
Послідовні записи в певному регістрі або пам'яті, повинні покинути це місце, що містить результат другого запису. Це може бути вирішено шляхом знищення (синоніми: скасування, анулювання, обговорення) першого запису, якщо це необхідно. WAW залежність також відома як вихідні дані.
Запис після читання (WAR)
При читанні з регістра або пам'яті повинно повертатися останнє значення, записане в цю область пам'яті і не єдина програмна запис після читання. Це свого роду помилкова залежність, яка може бути вирішена шляхом перейменована. WAR залежність також відома як анти-залежність.

Замість пізньої записи, почекайте, поки всі зчитування не будуть завершені, тоді дві копії дадуть старі і нові значення. Попередні зчитування, в програмному порядку, запишуть нові значення, які можуть бути надані зі старим значенням, навіть у той час, як інше зчитування слід записувати з новим значенням. Хибна залежність порушується і створюються додаткові можливості для поза чергового виконання. Коли всі зчитування строго значення буде успішним, воно може бути відкинуто. Це важлива концепція регістра перейменування. Все, що зчитується або записується, може бути перейменоване. Поки загальне призначення і регістр з плаваючою точкою найбільш обсуждаеми, прапор і статус регістрів або кожного окремого статусу бітів звичайно добре перейменовуються. Осередки пам'яті також можуть бути перейменовані, хоча це незвично робиться в ступеня досвіду в перейменуванні регістрів. Закритий магазин Transmeta Crusoe[en] processor's є формою перейменування пам'яті. Якщо програми утримуються від негайного повторного використання регістрів, немає ніякої необхідності перейменовувати регістр. Деякі набори команд (наприклад IA-64) мають дуже велике число регістрів за конкретно цієї причини. Є обмеження цього підходу:

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

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

Архітектурні регістри проти фізичних[ред.ред. код]

Програми машинного мови вказують лічені і записані в обмеженому наборі регістрів являють собою набір команд (ISA). Наприклад, Alpha ISA визначає 32 цілочисельних регістра, кожні 64 біта і 32 регістра з плаваючою точкою, теж 64 біта. Це архітектурні регістри. Програми, записані для процесорів, що працює набір Alpha команди будуть визначені операторами читання і запису цих 64 регістрів. Якщо програміст зупиняє програму в відладчик, то він може спостерігати вміст цих 64 регістрів (і деякий статус регістрів), щоб визначити прогрес машини. Один окремий процесор, який належить ISA, Alpha 21 264[en] має 80 цілочисельних регістрів і 72 фізичних з плаваючою крапкою. Тут, на чіпі Alpha 21264, 80 фізично розділених місць, які можуть зберігати результати цілочислових операцій і 72 місця де можемо зберігати результати операцій з плаваючою крапкою. (Насправді, тут більше місця, ер ці додаткові місця не підходять в операції перейменування регістрів.) Нижче описані два стилі перейменування регістрів, що відрізняються схемами, які містять готові дані для виконавчого блоку. У всіх перейменованих схемах, машина перетворює регістри з потокових команд в теги. Де архітектурні регістри можуть визначати від 3 до 5 бітів, теги зазвичай від 6 до 8 бітових чисел. Перейменування файлу може мати зчитує порт для кожного введення, для кожної інструкції перейменованої кожним циклом і записуючий порт для кожного виводу кожній інструкції перейменованої кожним циклом. Оскільки розмір реєстрового файлу зазвичай зростає пропорційно квадрату кількості портів, перейменування файлу, то це процес, що займає багато фізичних сил, і споживає значну потужність. У тего-індексованому регістровому стилі файлу є один великий регістровий файл для значень даних, що містять один регістр для кожного тега. Наприклад, якщо машина має 80 фізичних регістрів, тоді вона б використовувала 7 бітових тегів. 48 з можливих значень тегів в цьому випадку не використовуються. У цьому випадку, коли інструкція видається на виконавчий блок, мітки для вихідних регістрів надходять до фізично зареєстрованому файлу, де значення, відповідні цих мітках, зчитуються і передається на виконавчий блок. У випадку бронювання пункту є багато маленьких асоціативних реєстрових файлів, які зазвичай один на виході в кожному виконавчому пристрої. Кожний операнд кожної команди в проблемній черзі має місце для значення в одному з цих реєстрових файлів. У цьому випадку, коли команда видається виконавчому блоку, входження в регістровий файл повідомляє про входження в чергу, зчитується і передається в блок виконання.

Архітектурний Регістровий Файл (RRF)
Цілеспрямований регістр в машині. Оперативна пам'ять індексує логічним числом регістрів. Зазвичай записується в результаті видалення або прив'язаний з переупорядочивания буфера.
Майбутній файл
Самое ризиковане регістрове стан машини. Оперативна пам'ять індексує логічно регістрові числа.
Активний Регістровий Файл
Термін групи P6 Intel для майбутнього файлу.
Буфер історії
Зазвичай використовується в комбінації з Майбутнім Файлом. Складається з «старих» значень регістрів, які були перезаписані. Якщо продуктивність все ще відстає, це може бути оперативна пам'ять, яка індексується історією буфера чисел. Після відділення ізольованих помилок, вони повинні використовувати результат з історії буфера або їх копії, або якщо пошук в майбутнього файлу відключений і історія буфера CAM індексується логічними регістрами чисел.
Зміна порядку буфера (ROB)
Структура послідовно (циклічно) індексується на кожної базової операції, для кожного перебору команди. Він відрізняється від Буфера Історії, бо упор в буфері зазвичай приходить після Майбутнього Файлу (якщо він існує) і до архітектурного реєстрового файлу.

Буфери проходять зміна порядку у версіях зменшених і заповнених даних. У Willamette ROB, ROB входження вказують на регістри у фізичному файлі (PRF) і також містить інший бухгалтерський облік. Це також був перший вийшов з ладу дизайну зробленого Andy Glew разом з HaRRM. P6's ROB, ROB містить вхідні дані; ого не розділяється PRF. Значення даних з ROB копіюються з ROV в RRFпрі скасуванню. Одна маленька деталь: якщо є тимчасова неоднорідність записів ROB (т.е. Якщо команди близько один до одного в послідовності команд фон Неймана, запишіть назад по часу, наскільки це можливо, щоб записати об'єднання на ROB входженнях і мати кілька портів, які будуть розділені ROB / PRF). Не ясно, якщо він робить відмінності, коли PRF слід відкласти. ROB зазвичай не має асоціативний логіку і, звичайно, жоден з розроблених Andy Glew ROB'ов не має CAM. Keith_Diefendorff[en] наполягав, що ROB має складну асоціативну логіку вже багато років. Перше ROB можливо були CAM.

Подробиці: тег-індексовані файли регістрів[ред.ред. код]

Перейменування стилю використовується в MIPS: R10000[en], Alpha 21 264[en] і в розділі FP з AMD Athlon. У стадії перейменування, кожен архітектурний регістр посилання (для читання або запису) шукається в архітектурно-Индексируемая Перескладений файлі. Цей файл повертає мітку і готовність біта. Мітка не готова, якщо є черга команд, які будуть записувати в неї те, що ще не виконано. Для зчитується операндів, ця мітка займає місце в архітектурному регістрі в команді. Для кожного записуючого регістра, нова мітка витягнена з вільної мітки FIFO і нове відображення записується в Перескладений файл, так що майбутні команди зчитування архітектурних регістрів будуть ставитися до цієї нової мітці. Мітка позначається як не готовий, тому що команда не виконується. Попередній фізичний регістр виділений для цього архітектурного регістра і збережений з командою в буфері відновлення послідовності [en], котра є FIFO, містить команди в програмі для декодування і дипломних етапів. Команди поміщаються в різних проблемних чергах. Як тільки команди виконуються, мітки і проблемні черги для їх результатів транслюються, відповідаючи цим матюками на відміну від міток, не готових бути початком операндів. Відповідність означає, що операнд готовий. Перепризначений файл також відповідає цим матюками, так що вони можуть помітити відповідні фізичні регістри, як будуть готові. Коли всі операнди готові в проблемну чергу команд, команда готова до результату. Проблемні черзі підбирають готові команди для відправки в різні функціональні блоки в кожному циклі. Неготові команди залишаються в проблемних чергах. Неупорядковане видалення команд із проблемних черг є однією з речей, яка робить їх великий і енергоємної.

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

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

Подробиці: Резервне місце[ред.ред. код]

Цей стиль використовується в цілій частині конструкцій AMD K7 і K8. У стадії перейменування, кожен архітектурний реєстр посилається для зчитування та перегляду в обох архітектурно-індексованих 'майбутнього файлу' і файлу перейменування. Зчитування майбутнього файлу дає значення цього регістра, якщо немає невиконаних команд, ще не записаних до нього (тобто він готовий). Коли команда поміщається в проблемну чергу, значення зчитуються з майбутнього файлу і записуються у відповідні елементи в резервне місце. Регістр запише у файл новий процес, неготова мітка буде записана в перейменований файл. Кількість міток, як правило, послідовно виділяються в порядку - необхідна не вільна мітка FIFO.

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

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


Див. також[ред.ред. код]

Комп'ютер Це незавершена стаття про комп'ютери.
Ви можете допомогти проекту, виправивши або дописавши її.