Les processeurs ARM (récents et anciens) utilisent-ils un microcode? Si oui, alors pourquoi? Leurs instructions ne sont-elles pas assez simples pour être exécutées directement sans être traduites en micro-opérations?
12
TL, DR; Bien que les processeurs ARM utilisent des concepts similaires aux processeurs micro-codés (par exemple, il existe un bloc matériel qui décode les instructions en une ou plusieurs micro-opérations ), ils ne sont pas microcodés au sens traditionnel qui utilise une ROM pour stocker chaque micro-instruction, ni ces micro-instructions / opérations peuvent-elles être modifiées une fois produites dans le matériel réel. En effet, les processeurs ARM utilisent un contrôle câblé dans le décodeur d'instructions pour générer des micro-opérations.
En pratique, cependant, la modification du décodeur d'instructions peut être similaire à la modification d'un processeur microcodé, car ARM concède sous licence le code source du langage de description matérielle ( HDL ) de ses architectures CPU à des fabricants individuels, ce qui rend les modifications au niveau matériel beaucoup plus faciles à implémenter. Voir la section Décodeur d'instructions dans le Wikibook Microprocessor Design pour plus de différences entre les décodeurs d'instructions RISC et CISC typiques.
Bien que l'architecture ARM elle-même ne soit pas microcodée au sens traditionnel, les instructions individuelles sont décodées en micro-opérations plus petites . Un processeur ARM moderne est loin d'être "simple" - bien que les instructions elles-mêmes soient très orthogonales, il y a beaucoup de technologie moderne (par exemple pipelining, instructions superscalaires, exécution dans le désordre, mise en cache, instructions complexes étendues comme les unités à virgule flottante ou instructions NEON) qu’un noyau A9 moderne possède. En effet, n'importe quel processeur peut être assez simple à exécuter sans traduction en micro-opérations, mais cela consiste essentiellement à mettre "tous vos œufs dans le même panier" - vous ne pouvez pas corriger d'éventuels errata dans le jeu d'instructions, ni les étendre / modifier après la production.
Cependant, si nous ne parlons que de l' étape de décodage des instructions , alors de nombreux processeurs ARM ne sont pas microcodés de manière à permettre une modification après coup, bien que cela puisse être dû au fait que la plupart des fabricants concédant une technologie ARM ont accès à la technologie réelle code source matériel (écrit en HDL). Cela réduit la consommation d'énergie car une étape de microcode n'est pas nécessaire, mais les instructions individuelles sont "compilées" en blocs matériels réels. Cela permet également à chaque fabricant de corriger les errata.
En effet, même dans un processeur basé sur CISC (par exemple x86), il n'est pas nécessaire d'utiliser un microcode. Dans la pratique, cependant, la complexité du jeu d'instructions, combinée à diverses différences de licence, de consommation d'énergie et d'applications, rend le choix du microcode idéal pour le cas de x86. Dans le cas d'ARM, cependant, c'est moins utile car les modifications apportées au jeu d'instructions (décodeur) sont beaucoup plus faciles à mettre en œuvre et à contrôler en termes de matériel lui-même (car il peut être personnalisé par le fabricant).
Bien que le fait d'avoir un microcode puisse en fait simplifier la conception du processeur dans certains cas (comme chaque instruction existe en tant que "micro programme" par opposition au matériel réel), il ne s'agit en fait que d'un décodeur d'instructions (par exemple, l' extension Thumb-2 , permettant de les instructions de longueur doivent exister en ajoutant un décodeur d'instructions distinct en ligne avec le décodeur d'instructions ARM). Bien que fonctionnellement, ces unités puissent être implémentées à l'aide d'un microcode, cela ne serait pas judicieux en termes de consommation d'énergie, car vous devez définir la sortie de chaque signal de contrôle dans le CPU lui-même, même si cela n'est pas nécessaire. Cela ne signifie pas ont quoi que ce soit à voir avec la complexité du CPU lui-même, car les cœurs ARM ont toutes les constructions modernes auxquelles on peut s'attendre (pipelining, caches d'instructions / données, tampons micro-TLB, prédiction de branche, mémoire virtuelle, etc.) ).
Dans le cas d'ARM, étant donné l'orthogonalité du jeu d'instructions, la complexité impliquée dans la mise en œuvre d'une telle approche microcodée l'emporterait sur les avantages de simplement changer le matériel pertinent directement dans le bloc décodeur d'instructions. Bien que cela soit certainement possible, cela finit par "réinventer la roue" pour ainsi dire, étant donné que vous êtes capable de modifier directement (et de compiler / tester / émuler) les changements dans le matériel.
Vous pouvez "penser" au code source ARM lui-même comme un type de microcodage dans ce cas, bien qu'au lieu de stocker chaque micro-opération / micro-programme dans une ROM qui peut être modifiée après coup, ils sont implémentés directement dans matériel dans le décodeur d'instructions. Étant donné que le décodeur d'instructions lui-même est écrit en VHDL / Verilog, apporter des modifications aux instructions existantes est aussi simple que de modifier le code source, de recompiler et de tester le nouveau matériel (par exemple sur un FPGA ou un simulateur). Cela contraste avec la complexité du matériel x86 moderne, qui est beaucoup plus difficile à tester / simuler pendant le développement, et encore plus difficile à modifier après la production (car la taille en termes de transistors dépasse de loin ce que l'on peut exécuter à l'intérieur même le plus cher moderne FPGA, ajoutant ainsi un avantage à l'utilisation d'un magasin de microcodes).matériel physique utilisant un FPGA.