Деякі процесори мають регістр прапорів (ARM, x86, ...), інші - (MIPS, ...). Яка перевага в тому, щоб мати інструкцію CMP для оновлення реєстру прапорів, а потім інструкцію гілки замість того, щоб використовувати нульовий регістр та умовні гілки для перевірки ознак, переповнення тощо?
Відповіді:
У сучасних мікроархітектурах з реєстром, що перейменовує вартість реалізації прапорів чи не прапорів, досить схожа. Основна відмінність, яку я можу придумати, полягає в тому, що деякі прапори вказують на характеристики значення (Чи є значення від’ємним? Чи є значення нульовим? Чи має значення парне чи непарне парність?), А деякі представляють подію, що сталася під час попередньої операції (чи мала інструкція "add" виконувати чи переповнювати?) Це призвело до менш ідеальної ситуації на MIPS, коли ви хотіли імітувати 64-бітове додавання 32-бітної архітектури (або 128-бітове додавання на 64-розрядна архітектура.) Для більшості архітектур із прапором несуть спеціальнийadd-with-carryінструкція, що включає прапор перенесення з попередньої інструкції додати. Це робить моделювання багатоточної арифметики порівняно недорогим для багатьох архітектур з регістрами прапорів.
З іншого боку, тестування N-бітового регістра на нуль чи не-нуль насправді напрочуд дорого. Для тестування N-бітового регістра на нуль потрібно виконати операцію NOR-бітів NOR, для якої для обчислення потрібні рівні логіки . У архітектурах з прапорцями реєструється додаткова логіка для обчислення нуля / не-нуля в кінці етапу ALU може призвести до того, що годинник працює повільніше (або змусить АЛУ мати два циклові операції.) З цієї причини, я думаю, деякі архітектури, як і SPARC, мали дві версії кожної арифметичної операції, таку, яка встановлювала прапори, і та, яка не робила.
Але MIPS тут нічого не рятує. Вони просто перенесли проблему кудись інше. На MIPS є branch-on-equalінструкція. Це означає, що інструкція з гілки насправді повинна мати етап ALU (включаючи щось на зразок побітової xorоперації з подальшим norзменшенням до одиничного рівного / не рівного біта), перш ніж визначати, яким шляхом йде гілка.
Архітектура DEC Alpha намагалася розділити різницю за допомогою трюку. DEC Alpha не мав регістрів прапорів, але також не мав branch-on-equalінструкції. Натомість в галузевих інструкціях усі дивляться на стан єдиного реєстру загального призначення. Там буде branch-on-zero, branch-on-not-zero, branch-on-less-than-zeroі т.д. Хитрість полягає в тому, що ви можете дати кожен загального призначення зареєструвати додатковий біт 65 - ї , який говорить вам чи інші 64 біти рівні нулю чи ні. Це більше схоже на те, щоб мати реєстрацію прапорів: усі вказівки гілки дивляться на один біт (який уже розрахований), щоб прийняти своє рішення, але тепер ви повертаєтесь до з'ясування того, як обчислити цей додатковий нульовий біт індикатора під час звичайного ALU цикл. (І ви все одно не можете виконати багатоточну арифметику, просто подивившись на прапор перенесення з попередньої операції.)
Інструкції з тестування, які встановлюють лише прапори - це лише спосіб зменшити тиск у регістрі в архітектурах, голодуючих у регістрі. Якщо у вас достатньо регістрів, просто модифікуйте один з них і ігноруйте результат. Трюк мати регістр 0 зі вхідним значенням 0 - це лише хитрість кодування, зручна, коли у вас є достатня кількість регістрів, що фіксація одного з них до 0 - це краще, ніж збільшення кількості інструкцій. Тоді зручно використовувати його і як ціль (це зменшує кількість помилкових залежностей).
Кодування знову. Якщо ви кодуєте умову у стрибках, у вас будуть стрибки з трьома операндами (два для порівняння та ціль стрибка), два з яких ви хотіли б отримати негайні значення, один з яких ви хочете бути таким же великим, як можливо (стрибки часто мають власний формат кодування, щоб ціль могла використовувати якомога більше бітів). Або ви кидаєте можливості.
Використання прапорів дає більше можливостей їх встановити. Не тільки операції порівняння можуть встановлювати прапори, а все, що завгодно. (З застереженням, що чим більше операцій над встановленням прапорів, тим обережніше потрібно бути уважним, щоб остання операція, яка встановлювала прапори, була тією, яку ви хочете). Якщо у вас є прапори, ви можете перевірити кількість умов (найчастіше 16), помножених на кількість інструкцій, здатних встановити прапори (якщо ви не використовуєте прапори, у вас виходить приблизно стільки ж умовних стрибків, скільки ви є речі для тестування або є речі, які ви не дозволяєте тестувати так легко (наприклад, переносити або переповнювати).
Тестування прапорів легко і може бути швидко виконано. Чим складніший ваш тест, тим більший вплив він матиме на час циклу (або на структуру трубопроводу, якщо ви конвеєрні). Це особливо стосується більш простих реалізацій, коли ви потрапляєте на процесор високого класу, використовуючи всі хитрощі книги, ефект досить мінімальний.
Наявність прапорів означає, що багато інструкцій мають кілька результатів (природний результат та кожен із змінених прапорів). А з мікро-архітектури POV кілька результатів погані (ви повинні слідкувати за їх асоціацією). Якщо у вас є лише один набір прапорів, який вводить залежності (непотрібні, якщо прапор потім не використовується), вам доведеться обробляти так чи інакше. Знову це особливо актуально для більш простих реалізацій, коли ви потрапляєте на процесор високого класу, використовуючи всі хитрощі книги, додаткові труднощі спотворюються з боку решти процесора.
На 32-розрядній машині інструкція "додавання-перенесення", яка використовується як частина послідовності додавання з багатоточним складанням, повинна приймати операнди, вартістю 65 біт, і обчислити суму 33 біт. Специфікації регістрових джерел визначатимуть, звідки повинні надходити 64 біти операндів, а специфікація регістрового пункту призначення вказуватиме, куди мають піти нижні 32 біти результату, але що робити з операндом "додати один додатковий" або верхнім бітом результату? Дозволено вказувати як частину інструкції, звідки повинен надходити додатковий операнд, і куди повинен надходити додатковий біт результату, але це було б не дуже корисно, щоб виправдати додаткове поле в опкоді. Маючи фіксовану "локацію" для обробки прапора для перенесення, може бути трохи незручно з точки зору планування інструкцій, але це "
Якщо хтось намагався розробити набір інструкцій, який би дозволяв арифметику з високою точністю, але кожна інструкція була обмежена двома 32-бітовими операндами та одним 32-бітовим операндом призначення, можна було реалізувати 64-розрядне "додавання" у чотирьох інструкціях: "встановити r5 до 1, якщо r0 + r2 несе або дорівнює нулю в іншому випадку; обчислити r4 = r1 + r3; обчислити r5 = r4 + r5; обчислити r4 = r0 + r2 ", але виходячи за рамки цього потрібно три інструкції для кожного додаткового слова. Наявність прапора для перевезення в якості додаткового джерела та місця призначення зменшує вартість до однієї інструкції за кожне слово.
Зауважте, btw, що, маючи біт інструкцій, керувати, чи оновлення оновлення реєстру регістра прапора може полегшити виконання поза замовлення, оскільки інструкції, які використовують або змінюють біти прапора, повинні підтримувати свою послідовність один щодо одного, але інструкції, які не можуть ні бути вільно переставленим. Враховуючи послідовність:
ldr r0,[r1]
add r0,r0,r2
eors r4,r5,r6
підрозділ виконання міг досить легко визнати, що третя інструкція може виконуватись, не чекаючи, коли дані будуть прочитані [r1], але якби друга інструкція була adds r0,r0,r2такою, це було б можливо лише в тому випадку, якщо виконавчий блок міг би переконатися, що що-небудь намагається використовувати прапори, нульовий прапор буде містити значення, встановлене в третій інструкції, але прапор перенесення буде містити значення у другій.
Проста відповідь ... швидка дешева операція з пам'яттю, яка не вимагає абсолютно ніякого внутрішнього використання шин, крім самої інструкції. Він може використовуватися як стек bool із стеком чи процесом, без пам'яті.