В процессорах ARM (старых и старых) используется микрокод? Если так, то зачем? Разве их инструкции не достаточно просты, чтобы их можно было выполнить напрямую, не переводя их в микрооперации?
1 ответ
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, таким образом добавляя преимущество использованию магазина микрокодов). Конечно, тот же факт относится и к ARM, но разница в разработке - можно вносить изменения в аппаратное обеспечение процессора, а затем непосредственно просматривать / тестировать изменения на физическом оборудовании с помощью ПЛИС.