Чи використовують процесори ARM типу cortex-a9 мікрокод?


12

Чи використовують процесори ARM (останні та старі) мікрокод? Якщо так, то для чого? Чи не є їхні інструкції досить простими, щоб виконуватись безпосередньо, не перекладаючись на мікро-операції?

Відповіді:


14

TL, DR; Хоча процесори ARM використовують подібні поняття для мікрокодированних процесорів (наприклад, є апаратний блок, який розшифровує інструкції в одну або кілька мікрооперацій ), вони не мікрокодуються в традиційному розумінні, що використовує ПЗУ для зберігання кожної мікроінструкції, а також чи можуть бути змінені ці мікроінструкції / операції після того, як вони виробляються на фактичному обладнання. Дійсно, процесори ARM використовують жорстке провідне управління в інструкції декодера для генерації мікрооперацій.

На практиці, однак, модифікація декодера інструкцій може бути схожа на зміну мікрокодованого процесора, оскільки ARM ліцензує вихідний код апаратного опису ( HDL ) вихідних кодів своїх архітектур процесора окремим виробникам, що робить модифікації рівня апаратури значно простішими у здійсненні. Дивіться розділ « Інструкція декодера» у Вікібуді з мікропроцесорного дизайну для отримання додаткових відмінностей між типовими декодерами інструкцій RISC та CISC.


Хоча сама ARM архітектура НЕ microcoded в традиційному сенсі, окремі інструкції будуть декодируется в невеликі мікроопераціях . Сучасний процесор ARM далеко не "простий" - хоча самі інструкції є дуже ортогональними, існує маса сучасних технологій (наприклад, конвеєрне, суперскалярні інструкції, виконання поза замовленням, кешування, розширені складні інструкції, такі як одиниці з плаваючою комою. або інструкції NEON), якими володіє сучасне ядро ​​A9. Дійсно, будь-який процесор може бути досить простим для виконання без перекладу на мікрооперації, але це по суті поміщення "всіх ваших яєць в один кошик" - ви не можете виправити жодних можливих помилок у наборі інструкцій, а також не розширити / змінити його після виробництва.

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

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


Хоча наявність мікрокоду може фактично спростити конструкцію процесора в деяких випадках (оскільки кожна інструкція існує як "мікропрограма" на відміну від реального обладнання), це фактично просто декодер інструкцій (наприклад, розширення Thumb-2 , що дозволяє інструкції по довжині існують шляхом додавання окремого декодера інструкцій, що відповідає декодеру інструкцій ARM). Хоча функціонально ці блоки можуть бути реалізовані за допомогою мікрокоду, це не було б розумно з точки зору енергоспоживання, оскільки потрібно визначити вихід для кожного керуючого сигналу в самому процесорі, навіть якщо це не потрібно. Це не так не має нічого спільного з тим, наскільки "складним" є сам власний процесор, оскільки ядра ARM мають усі сучасні конструкції, на які можна було б очікувати (конвеєрне керування, кеш-інструкції / дані, буфери мікро-TLB, передбачення гілок, віртуальна пам'ять тощо ... ).

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


У цьому випадку ви можете «мислити» сам вихідний код ARM як тип мікрокодування, хоча замість того, щоб зберігати кожну мікрооперацію / мікропрограму в ПЗУ, яку можна змінити за фактом, вони реалізуються безпосередньо в обладнання в декодері інструкцій. З огляду на те, що сам декодер інструкцій записаний у VHDL / Verilog, внесення змін до існуючих інструкцій так само просто, як зміна вихідного коду, перекомпіляція та тестування нового обладнання (наприклад, на FPGA або на тренажері). Це контрастує зі складністю сучасного обладнання x86, яке набагато складніше перевірити / моделювати під час розробки, а ще складніше модифікувати після виробництва (оскільки розмір транзисторів значно перевищує те, що можна запустити всередині навіть найдорожчого сучасного FPGA, тим самим додаючи перевагу використання магазину мікрокодів).фізичне обладнання за допомогою FPGA.


Отже, мікрокод ARM знаходиться на апаратному забезпеченні, правда?
Kraken

1
@Kraken у певному сенсі, так; замість використання мікро-послідовника кожна інструкція переводиться декодером інструкцій безпосередньо в окремі мікро-операції / мікроінструкції (один або кілька тактових циклів) для цього коду. Стаття « Декодер інструкції» з Вікікниги мікропроцесорного дизайну також корисна для пояснення відмінностей між типовими декодерами інструкцій RISC та CISC.
Прорив

Дякую. Це для мене багато чого прояснює. Знову дякую. +1 за зусилля.
Кракен
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.