Алгоритм Томаслу: Виконання без послідовності та Перейменування регістрів

Проблема: Залежності, які насправді не існують

Дані залежності між інструкціями мають три форми, і лише одна з них є справжньою, невід’ємною залежністю. Читання після запису (RAW), коли інструкція потребує значення, яке ще не було вироблено попередньою інструкцією, – це справжня залежність, яку необхідно поважати незалежно від будь-чого. Але загрози типу запис після запису (WAW) та запис після читання (WAR) є наслідками обмеженого набору архітектурних регістрів, які повторно використовуються в програмі, а не справжнім потоком даних. Якщо інструкція 1 записує в регістр R1, інструкція 2 читає R1, а інструкція 3 пізніше знову записує R1 з абсолютно не пов’язаним значенням, наївна машина, що виконується поза чергою, ризикувала б перезаписати R1 перед тим, як інструкція 2 прочитала оригінальне значення, або результати записувалися назад у неправильному порядку і залишали R1 з застарілим значенням. Ці залежності називаються хибними, тому що вони не несуть жодної фактичної інформації від однієї інструкції до іншої; вони існують лише через те, що компілятор вичерпав наявність регістрів і переробив R1 для чогось нового. Ранні процесори або приймали ризик отримання зупинок, або потребували розумного компілятора для обходу цих проблем шляхом вибору різних регістрів.

Станції резервування: Буферизація до готовності

У серці проєкту Томаслу знаходяться станції резервування – невеликі буфери, пов’язані з кожним функціональним блоком, таким як додатки або множники, які зберігають відправлене інструкцію разом із її операндами або, якщо значення ще недоступне, тег, що ідентифікує інструкцію, яка зрештою його виробить. Коли інструкція відправляється, вона призначається для вільного стану резервування відповідного функціонального блоку; якщо обидва її операнди вже доступні в регістровому файлі або передаються з нещодавно завершеної інструкції, вони копіюються негайно, інакше станція резервування записує тег створюваної інструкції замість значення. Важливо зазначити, що відправка не зупиняється через очікування операндів; інструкція просто знаходиться у своєму стані резервування, і виконання починається в момент фактичного надходження всіх її позначених операндів, незалежно від того, що має відбутися за програмою. Це саме так виконуються незалежні інструкції поза чергою: інструкція, чиї операнди готові, може почати виконуватися, поки раніша, все ще відправлена, інструкція чекає на виготовлення значення. Станції резервування ефективно відокремлюють питання про те, коли інструкція завантажується та декодується, від питання про те, чи має вона все необхідне для виконання, перетворюючи порядок програми на розпливчастий сигнал для етапу виконання, а не жорстку вимогу.”]}**”**

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

Алгоритм Томаслу реалізує перейменування регістрів без окремого фізичного файлу регістрів, як це роблять пізніші архітектури, такі як MIPS R10000; замість цього він використовує простий, але потужний трюк обліку. Таблиця статусу регістрів відстежує для кожного архітектурного регістру, яка станкова комірка (якщо така є) зараз утримує інструкцію, що генеруватиме його наступне значення. Коли інструкція, що записує в регістр R1, надсилається, таблиця статусу регістрів негайно оновлюється, щоб вказувати на тег станкової комірки цієї інструкції, щоб будь-яка пізня інструкція, яка читає R1 до завершення запису, автоматично отримує правильний, найновіший тег виробника замість застарілого значення. Цей механізм безкоштовно вирішує проблеми WAW і WAR, оскільки кожен запис отримує свіжий тег замість перезапису фіксованого фізичного місця; пізній запис до того ж самого архітектурного регістру просто стає іншим тегом, і будь-які попередні читання, які вже зафіксували попередній тег, не впливають на те, що відбувається з цим регістром після цього. Фактично, невеликий, фіксований набір архітектурно видимих регістрів динамічно відображається у значно більшому, неявному просторі позначених значень, одне для кожної інструкції, що виконується, яка записує в регістр, що є точно тим, що сучасні перейменування регістрів роблять явно з великими фізичними файлами регістрів. Гений оригінальної схеми Томаслу полягав у тому, що він досяг цієї поведінки перейменування як емерджентної властивості на основі станкових комірок із зарезервованими тегами, а не вимагав окремого апаратного забезпечення для перейменування.

Загальна дані та виконання поза послідовністю

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

Від IBM 360/91 до кожної сучасної ЦП

Роберт Томаслу спроєктував цю схему спеціально для того, щоб IBM System/360 Model 91 з її плаваючою десятковою арифметикою, яка мала множники та дільники з різними затримками, могла підтримувати незалежні операції, не зупиняючись за повільним пристроєм. Близько двох десятиліть ця ідея залишалася в основному академічною цікавістю поза межами спеціальних суперкомп'ютерів, поки на початку 1990-х років вона стала основою для практично кожної основної архітектури з винесенням за межі порядку виконання: Intel Pentium Pro представив об’єднаний резервний пункт призначення та буфер перестановки, безпосередньо натхненні підходом Томаслу, і його спадкоємці продовжуються у всіх наступних поколіннях процесорів Intel Core. AMD, високопродуктивні ядра ARM та лінія POWER від IBM сьогодні використовують концептуально еквівалентні структури, зазвичай поєднані з окремим буфером перестановки, який відстежує порядок програми, щоб результати, хоч і обчислюються поза порядком, були підтверджені в архітектурному стані (використані) у правильному порядку, що є важливим для точних винятків та для ілюзії послідовного виконання, на яку покладається коректність програмного забезпечення. Сучасні реалізації використовують великі фізичні файли регістрів та таблиці перейменування замість оригінального буфера Томаслу з відповідністю тегу трансляції, оскільки спільний буфер трансляції не масштабується до десятків одночасно в польоті інструкцій на сьогоднішніх чіпах, але концептуальна спадкоємність безпосередня та неоспорна. Коли ви використовуєте будь-який сучасний високопродуктивний процесор, від смартфона до серверу центрів обробки даних, ймовірно, інструкції розраховуються апаратним забезпеченням, що успадковує дух дизайну, побудованого для прискорення арифметики з плаваючою десятковою кратною на 1967 році головному комп’ютері.

Часті запитання

Спробуйте наживо

Усе, що вище, працює прямо у вашому браузері — відкрийте Tomasulo's Algorithm: Out-of-Order Execution & Register Renaming і змінюйте параметри під час роботи. Нічого не встановлюється, нічого не завантажується на сервер, уся модель живе в одній вкладці.