Є багато причин, з яких можна було б запровадити впровадження CISC. Найвизначніша причина - сумісність із двійковою формою з існуючим набором інструкцій CISC. Хоча технологія бінарного перекладу програмного забезпечення вдосконалюється, сумісність на основі апаратних засобів має деякі технічні переваги (а також недолік меншого кешування перекладу) та меншу технічну перевагу, здається, більш надійною.
Щільність коду є чи не другою найбільш важливою причиною вибору CISC. Renesas RX був розроблений як CISC спеціально для щільності коду, оскільки він орієнтований на мікроконтролери, де розмір кодової пам'яті є значним фактором витрат. Інструкції зі змінною довжиною, складні інструкції (в основному більше режимів адресації), неявні операнди та нижчий регістр рахують всю щільність коду вигоди.
Історичною (і на мій погляд, неправильною) причиною вибору CISC було закриття смислового розриву між програмістами, що використовують мову вищого рівня, та процесором. Оскільки складні інструкції зазвичай можуть бути замінені послідовністю більш простих інструкцій, складність компілятора мови вищого рівня для RISC не повинна бути набагато складнішою, ніж для CISC, що відповідає мові. RISC уникає "семантичного зіткнення" (де інструкція процесора робить більш-менш роботу, ніж відповідна мова мови) та полегшує оптимізацію сили та планування. (Див «Які компроміси в спробі розробки компілятора , пов'язану з CISC проти RISC?» Для отримання більш докладної інформації.)
Можуть бути значні постійні витрати, пов'язані з виконанням інструкції. Це заохочує використання відносно складних інструкцій, щоб розповсюдити цей наклад над більш актуальною роботою; зменшення кількості динамічних інструкцій може підвищити продуктивність. Коли вартість логіки та оперативної пам’яті була значно більшою, ніж вартість ПЗУ, стимул до складних інструкцій був значним, оскільки інструкція розшифровувалася шляхом пошуку мікрокоду.
Причиною використання CISC, що, можливо, суперечить історичним свідченням, є те, що мікрокод можна оптимізувати для кожної мікроархітектури, тоді як стандартні бібліотеки можуть повільно використовувати функції нової реалізації. Рівень оптимізації програмних реалізацій мемокопії порівняно з мікрокодом для REP MOVSB означає, що бібліотекам можна приділяти більше уваги, ніж мікрокоду. Частина цього може надходити від постачальника процесорів, орієнтованого на більш широку базу користувачів, тому обґрунтування зусиль може бути складніше порівняно з відкритим кодом або внутрішнім програмним забезпеченням, коли локалізовані інтереси розробників або користувачів можуть упереджувати зусилля щодо впровадження.
Можливість доставки оптимізованої стандартної бібліотеки з процесором має значні привабливості. Зберігання та виконання стандартної бібліотеки платформи може бути значно оптимізовано програмно-апаратним кодовим дизайном. Відмінність між складною інструкцією та викликом шару абстракції платформи може бути тонким (або неіснуючим). Дизайн RISC може використовувати ті самі методи реалізації для обробки PAL-дзвінків, що і CISC, для складних інструкцій, включаючи використання операцій, не передбачених загальним набором інструкцій із спеціалізованим обладнанням, використання розумного кешування та декодування, а також визначення операндів реєстру (хоча CISC би часто використовують спеціалізовані регістри, подібні до функцій ABI). Ментальна модель, пов'язана з CISC, може заохочувати такі оптимізації. Крім того, користувачі можуть бути менш ображені примусовим включенням "
Розшифровка відносно складних інструкцій може мати менші накладні витрати (і, можливо, надійніше бути правильними в розбірці намірів), ніж порівнянна методика розпізнавання ідіоми RISC, коли послідовність інструкцій визнається семантичною одиницею. Ця різниця накладних була б найбільш помітна в меншій реалізації, але накладні витрати на використання цієї інформації зменшують значення економії декодування.
Додаткова контекстна інформація може полегшити оптимізацію обладнання. Наприклад, при збільшенні значення в пам'яті апаратне забезпечення може визнати, що адреса пам'яті використовується двічі (для завантаження та зберігання), надаючи можливість для кешування способу запам'ятовування та кешування перекладу. Складні інструкції можуть надавати таку інформацію прямо. У складній інструкції проміжні значення мають явний термін експлуатації (термін інструкції); з традиційними значеннями регістра RISC повинні бути явно переписані, щоб вказати кінець терміну дії. (Примітка. RISC може вказати реєстр, який завжди нульовий після кожного використання, надаючи засоби для визначення тимчасового значення для одноразового використання. Такі вказівки будуть дещо складнішими.)
Якщо деталі реалізації не ховаються за шаром абстракції, використовувати різні мікроархітектури стає складніше для оптимізації для різних компромісів. Розкриття мікроархітектурних деталей як архітектурних гарантій фіксує мікроархітектуру в гарантії сумісності. Хоча програмне забезпечення PAL можна оптимізувати так само, як і складні інструкції, таке вимагає апаратно-програмного кодування. Організаційне відокремлення та різноманітність ускладнюють кодирування.
Складні інструкції можуть забезпечити охоронений доступ до пільгового стану. Наприклад, складні інструкції часто є атомними щодо переривань. Хоча набір інструкцій RISC може забезпечити механізм рівня користувача, щоб тимчасово зупинити переривання, можливо, навіть щось на зразок зв'язаного навантаження, щоб програмне забезпечення явно повторювало операцію при перериванні, якщо таке не є типовим для RISC.
Аналогічно, складна інструкція може забезпечити контрольований доступ та / або використання привілейованої інформації. Оскільки виконана операція має керовану семантику, фактичного порушення привілеїв можна уникнути. Альтернативи, орієнтовані на RISC, включають код PAL (який, як правило, має значні накладні витрати) та маскований доступ до регістрів конфігурації (або тіньових копій регістрів), які мають певний привілейований стан. Надання загального рішення (RISC) складніше, ніж надання рішення для одного або кількох спеціальних випадків (CISC), але є більш потужним та менш вразливим до накопичення спеціальних справ. Якщо вірити, що важливих особливих випадків мало, CISC може бути більш привабливим.
Складні інструкції також можуть приховувати стан програмного забезпечення. Однією з видатних переваг цього було б збереження контексту та відновлення. Завдяки інструкціям, що зберігають і відновлюють стан, архітектурі потрібно лише передавати розмір контексту в ОС, а не конкретні механізми передачі стану в пам'ять. Це дозволяє програмам, що працюють на застарілій ОС, використовувати розширення ISA, які додають стан. (Знову ж таки, програмне забезпечення PAL могло б забезпечити той самий функціонал.)
Значна складність x86 пов'язана з сумісністю багатьох розширень. Завдяки складним та менш ортогональним інструкціям (корисно для щільності коду), видалення деяких робіт, які, як виявилося, не є загально потрібними, уникання зайвих ланцюгів залежностей (наприклад, лише один біт переносу, лише один регістр кількості динамічного зсуву), додавання певної роботи, яка перетворилася , щоб бути загальновживаним, і це можна оптимізувати в рамках складної інструкції - будь-яка з них вимагає додати нову інструкцію та зробити ISA менш естетично приємною.
У багатьох випадках RISC не стикається з такими питаннями, оскільки інструкції є високо ортогональними та примітивними. У деяких випадках RISC може знадобитися для додавання нових примітивів, але такі, як правило, застосовуються для більш ніж одного використання.
Крім того, після створення інфраструктури для підтримки складних інструкцій бар'єри зменшуються для додаткових складних інструкцій. Тобто велика частина витрат на складні інструкції не повторюється. Сильно МСС RISC зазнають додаткової перешкоди для впровадження функцій CISCy.
Частоту розширення x86 можна також частково віднести до його популярності для обчислень загального призначення та торгової моделі процесорів (вони також збільшують значення бінарної сумісності). RISC ISA часто пов'язуються з постачальниками sysem, що заохочує більш вузьку увагу до застосувань, а відсутність конкуренції за впровадження конкретних ISA RISC дещо перешкоджає використанню розширень набору інструкцій для маркетингу. Популярність також робить витрати на розробку нових розширень менш істотними (непостійні витрати є менш важливими при більшому обсязі).
Філософія сумісності x86, ймовірно, також спрямована на розширення існуючих механізмів, а не на забезпечення більш чистого перерви, що означає, що на нові функції більше впливають існуючі функції. Більш висока частота розширення також заохочує більш поступові зміни, що заохочує повторне використання механізмів, прагнучи зменшити ортогональність.
Порівнюючи академічну презентацію класичного MIPS (який є підмножиною сучасних версій MIPS і виключає різні необов'язкові розширення ISA) з сучасним x86 (який відстежує бінарну сумісність назад до 16-бітового 8086 і квазі-сумісності на рівні складання ще далі) з усім своїм історичним багажем не є найкращим випадком для CISC, ані реалістичним для RISC.