Используют ли процессоры ARM, такие как cortex-a9, микрокод?

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

Однако на практике модификация декодера команд может быть аналогична модификации микрокодированного процессора, поскольку ARM предоставляет лицензии на исходный код языка описания аппаратных средств ( HDL) своих архитектур ЦП отдельным производителям, что значительно упрощает реализацию модификаций на аппаратном уровне. См. Раздел " Декодер инструкций" в Wikibook "Микропроцессорное проектирование", чтобы узнать больше о типичных декодерах команд RISC и CISC.

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

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

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

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

В случае ARM, учитывая ортогональность набора команд, сложность, связанная с реализацией такого микрокодированного подхода, перевесила бы преимущества простого изменения соответствующего аппаратного обеспечения непосредственно в блоке декодера команд. Хотя это, безусловно, возможно, в конечном итоге это "изобретает колесо", так сказать, если вы способны непосредственно изменять (и компилировать / тестировать / эмулировать) изменения в оборудовании.

В этом случае вы можете "думать" о самом исходном коде ARM как о типе микрокодирования, хотя вместо того, чтобы хранить каждую микрооперацию / микропрограмму в ПЗУ, которое может быть изменено впоследствии, они реализуются непосредственно в Аппаратное обеспечение в инструкции декодера. Поскольку сам декодер команд написан на VHDL/Verilog, внести изменения в существующие инструкции так же просто, как изменить исходный код, перекомпилировать и протестировать новое оборудование (например, на FPGA или на симуляторе). Это контрастирует со сложностью современного аппаратного обеспечения x86, которое намного сложнее тестировать / моделировать во время разработки и еще труднее модифицировать после производства (поскольку размер в терминах транзисторов намного превышает то, что можно запустить внутри даже самого дорогого современного FPGA, таким образом добавляя преимущество использованию магазина микрокодов). Конечно, тот же факт относится и к ARM, но разница в разработке - можно вносить изменения в аппаратное обеспечение процессора, а затем непосредственно просматривать / тестировать изменения на физическом оборудовании с помощью FPGA.