В процессорах ARM (старых и старых) используется микрокод? Если так, то зачем? Разве их инструкции не достаточно просты, чтобы их можно было выполнить напрямую, не переводя их в микрооперации?
12
TL, DR; Хотя процессоры ARM используют концепции, аналогичные микрокодированным ЦП (например, имеется аппаратный блок, который декодирует инструкции в одну или несколько микроопераций ), они не имеют микрокодирования в традиционном смысле, который использует ПЗУ для хранения каждой микроинструкции, а также Могут ли эти микрокоманды / операции быть изменены после того, как они произведены на реальном оборудовании Действительно, процессоры ARM используют аппаратное управление в декодере команд для генерации микроопераций.
Однако на практике модификация декодера команд может быть аналогична модификации микрокодированного процессора, поскольку ARM предоставляет лицензии на исходный код языка описания аппаратных средств ( HDL ) своих архитектур ЦП отдельным производителям, что значительно упрощает реализацию изменений на уровне оборудования. См. Раздел « Декодер инструкций» в Wikibook «Микропроцессорное проектирование», чтобы узнать больше различий между типичными декодерами команд RISC и CISC.
Хотя сама ARM архитектура не microcoded в традиционном смысле, отдельные инструкции будут декодируется в небольшие микрооперациях . Современный процессор ARM далеко не «прост» - хотя сами инструкции очень ортогональны, существует много современных технологий (например, конвейерная обработка, суперскалярные инструкции, неупорядоченное выполнение, кэширование, расширенные сложные инструкции, такие как блоки с плавающей запятой). или NEON инструкции), что есть в современном ядре A9. Действительно, любой процессор может быть достаточно простым для выполнения без перевода в микрооперации, но это, по сути, складывает «все яйца в одну корзину» - вы не можете ни исправить возможные ошибки в наборе команд, ни расширить / изменить их после производства.
Однако, если мы говорим только о стадии декодирования инструкций , то на самом деле многие процессоры ARM не имеют микрокодирования таким образом, который допускает последующую модификацию, хотя это может быть связано с тем, что большинству производителей, лицензирующих технологию ARM, предоставляется доступ к фактическим данным. аппаратный исходный код (написанный на HDL). Это снижает энергопотребление, поскольку этап микрокода не требуется, но отдельные инструкции «скомпилированы» в реальные аппаратные блоки. Это также позволяет исправлять ошибки каждого производителя.
Действительно, даже в процессоре на основе CISC (например, x86) нет требования к использованию микрокода. Однако на практике сложность набора инструкций в сочетании с различными различиями в лицензировании, энергопотреблении и приложениях делают выбор микрокода идеальным для случая x86. Однако в случае ARM это менее полезно, поскольку изменения в наборе команд (декодере) намного проще реализовать и контролировать с точки зрения самого оборудования (так как оно может быть настроено производителем).
Хотя наличие микрокода может на самом деле упростить конструкцию процессора в некоторых случаях (поскольку каждая команда существует как «микропрограмма», а не фактическое аппаратное обеспечение), это фактически просто декодер команд (например, расширение Thumb-2 , позволяющее переменную длина инструкций существует путем добавления отдельного декодера команд в линию с декодером команд ARM). Хотя функционально эти блоки могут быть реализованы с использованием микрокода, это не будет разумно с точки зрения энергопотребления, так как вам необходимо определить выход для каждого управляющего сигнала в самом CPU, даже если это не требуется. Это не однако имеет отношение к тому, насколько «сложен» сам фактический процессор, поскольку ядра ARM имеют все современные конструкции, которые можно было бы ожидать (конвейерная обработка, кэши команд / данных, буферы микро-TLB, предсказание ветвлений, виртуальная память и т. д.) ).
В случае ARM, учитывая ортогональность набора команд, сложность, связанная с реализацией такого микрокодированного подхода, перевесила бы преимущества простого изменения соответствующего оборудования непосредственно в блоке декодера команд. Хотя это, безусловно, возможно, в конечном итоге это «изобретает колесо», так сказать, если вы способны непосредственно изменять (и компилировать / тестировать / эмулировать) изменения в оборудовании.
В этом случае вы можете «думать» о самом исходном коде ARM как о типе микрокодирования, хотя вместо того, чтобы хранить каждую микрооперацию / микропрограмму в ПЗУ, которое может быть изменено впоследствии, они реализуются непосредственно в аппаратное обеспечение в декодере команд. Поскольку сам декодер команд написан на VHDL / Verilog, внести изменения в существующие инструкции так же просто, как изменить исходный код, перекомпилировать и протестировать новое оборудование (например, на FPGA или на симуляторе). Это контрастирует со сложностью современного аппаратного обеспечения x86, которое намного сложнее тестировать / моделировать во время разработки и еще труднее модифицировать после производства (поскольку размер в терминах транзисторов намного превышает то, что можно запустить внутри даже самого дорогого современного FPGA, таким образом добавляя преимущество использованию магазина микрокодов).физическое оборудование с использованием ПЛИС.