Os processadores ARM como o córtex-a9 usam microcódigo?


12

Os processadores ARM (recentes e antigos) usam microcódigo? Se sim, então para quê? Suas instruções não são simples o suficiente para serem executadas diretamente sem serem traduzidas para micro-operações?

Respostas:


14

TL, DR; Embora os processadores ARM usem conceitos semelhantes aos processadores microcodificados (por exemplo, existe um bloco de hardware que decodifica instruções em uma ou mais micro operações ), eles não são microcodificados no sentido tradicional que usa uma ROM para armazenar cada micro instrução, nem Essas micro-instruções / operações podem ser modificadas depois de produzidas em hardware real. De fato, os processadores ARM usam controle com fio no decodificador de instruções para gerar micro-operações.

Na prática, no entanto, modificar o decodificador de instruções pode ser semelhante a modificar um processador microcodificado, porque o ARM licencia o código fonte da linguagem de descrição de hardware ( HDL ) de suas arquiteturas de CPU para fabricantes individuais, tornando as modificações no nível do hardware significativamente mais fáceis de implementar. Consulte a seção Decodificador de instruções no Wikibook de design de microprocessador para obter mais diferenças entre os decodificadores de instruções RISC e CISC típicos.


Embora a arquitetura do ARM em si não seja microcodificada no sentido tradicional, instruções individuais são decodificadas em micro-operações menores . Um processador ARM moderno está longe de ser "simples" - embora as instruções sejam muito ortogonais, há muita tecnologia moderna (por exemplo, pipelining, instruções superescalares, execução fora de ordem, armazenamento em cache, instruções complexas estendidas, como unidades de ponto flutuante ou NEON) que um núcleo A9 moderno possui. De fato, qualquer processador pode ser simples o suficiente para ser executado sem tradução para micro-operações, mas isso significa colocar "todos os seus ovos em uma cesta" - você não pode corrigir nenhuma errata possível no conjunto de instruções, nem expandi-la / modificá-la após a produção.

No entanto, se estamos falando apenas do estágio de decodificação das instruções , na verdade muitos processadores ARM não são microcodificados de maneira a permitir modificações posteriores ao fato, embora isso ocorra porque a maioria dos fabricantes que licenciam a tecnologia ARM tem acesso à impressora real. código fonte do hardware (gravado em HDL). Isso reduz o consumo de energia porque não é necessário um estágio de microcódigo, mas as instruções individuais são "compiladas" em blocos de hardware reais. Isso também permite a correção de erratas por cada fabricante.

De fato, mesmo em uma CPU baseada em CISC (por exemplo, x86), não há requisitos para o uso de microcódigo. Na prática, no entanto, a complexidade do conjunto de instruções, combinada com várias diferenças de licenciamento, consumo de energia e aplicativos, tornam a escolha do microcódigo ideal para o caso do x86. No caso do ARM, no entanto, é menos útil, pois as alterações no conjunto de instruções (decodificador) são muito mais fáceis de implementar e controlar em termos do próprio hardware (pois pode ser personalizado pelo fabricante).


Embora o microcódigo possa realmente simplificar o design do processador em alguns casos (como cada instrução existe como um "microprograma" em oposição ao hardware real), isso é efetivamente apenas um decodificador de instruções (por exemplo, a extensão Thumb-2 , permitindo variáveis). instruções de comprimento, adicionando um decodificador de instruções separado , alinhado com o decodificador de instruções ARM). Embora funcionalmente essas unidades possam ser implementadas usando microcódigo, isso não seria prudente em termos de consumo de energia, pois você precisa definir a saída para cada sinal de controle na própria CPU, mesmo que não seja necessário. Isso não no entanto, tem algo a ver com a complexidade da própria CPU, já que os núcleos ARM têm todas as construções modernas que se esperaria (pipelining, caches de instruções / dados, buffers micro-TLB, previsão de ramificação, memória virtual, etc ... )

No caso do ARM, dada a ortogonalidade do conjunto de instruções, a complexidade envolvida na implementação dessa abordagem microcodificada superaria os benefícios de simplesmente alterar o hardware relevante diretamente no bloco decodificador de instruções. Embora isso seja certamente possível, ele acaba "reinventando a roda", por assim dizer, desde que você seja capaz de modificar diretamente (e compilar / testar / emular) as alterações no hardware.


Você pode "pensar" no próprio código-fonte do ARM como um tipo de microcodificação nesse caso, embora, em vez de armazenar cada microoperação / microprograma em uma ROM que possa ser modificada posteriormente, eles sejam implementados diretamente no hardware no decodificador de instruções. Dado que o decodificador de instruções em si é escrito em VHDL / Verilog, fazer alterações nas instruções existentes é tão simples quanto modificar o código fonte, recompilar e testar o novo hardware (por exemplo, em um FPGA ou em um simulador). Isso contrasta com a complexidade do hardware x86 moderno, que é muito mais difícil de testar / simular durante o desenvolvimento e ainda mais difícil de modificar após a produção (já que o tamanho em termos de transistores excede em muito o que se pode executar dentro dos modernos modernos mais caros. FPGAs, adicionando um benefício ao uso de um armazenamento de microcódigo).hardware físico usando um FPGA.


Então, o microcódigo da ARM reside no hardware, certo?
Kraken

1
@Kraken em certo sentido, sim; em vez de usar um microsequenciador , cada instrução é traduzida pelo decodificador de instruções diretamente nas micro-operações / micro-instruções individuais (um ou mais ciclos de clock) para esse código de operação. O artigo Instructor Decoder do Microprocessor Design Wikibook também é útil para explicar as diferenças entre os decodificadores de instruções típicos RISC e CISC.
Breakthrough

obrigado. Isso esclarece muito para mim. Obrigado novamente. +1 para o esforço.
Kraken
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.