Réponses:
À ma connaissance, les instructions THUMB ne sont pas intrinsèquement plus lentes que les instructions ARM, mais leur capacité est plutôt limitée. Si votre code n'a besoin que de la fonctionnalité des instructions THUMB, il occupera moins d'espace que ARM, mais serait le même nombre d'instructions et, toutes choses étant égales par ailleurs, fonctionnera à la même vitesse. Si votre code a besoin de plus de fonctionnalités, il nécessiterait plus d'instructions THUMB que d'instructions ARM pour s'exécuter et prendrait plus de temps, toutes choses étant égales par ailleurs (voir ci-dessous)
THUMB est populaire dans les microcontrôleurs en raison des instructions de plus petite taille pour deux raisons:
Pour la deuxième raison, lorsque votre code ne nécessite aucune fonctionnalité du jeu d'instructions ARM, le code THUMB s'exécute en fait plus rapidement. En effet, vos instructions peuvent être récupérées dans un cycle d'E / S à partir du flash au lieu de deux. Selon la vitesse de votre interface flash, cette deuxième lecture peut entraîner un ou plusieurs cycles d'attente par instruction, où votre processeur est simplement bloqué et ne peut rien faire.
Cela devient moins problématique si vous pouvez copier votre code sur la RAM avant de l'exécuter (ce que j'ai généralement vu comme 32 bits pour les microcontrôleurs ARM récents), où le seul problème est la densité du code. Pour cela, de nombreux outils tenteront de trouver la représentation la plus efficace pour une fonction donnée. Si le compilateur peut produire du code THUMB en moins d'instructions, il le fera, mais si ARM entraîne moins d'instructions, vous obtenez ARM. C'est le mode par défaut pour Keil, si je me souviens bien.
Pour votre puce particulière (AT91SAM7S32), la documentation mentionne que le contrôleur flash a un tampon de prélecture qui peut prédire les accès pour rendre les choses plus efficaces, ce qui pourrait améliorer l'exécution des instructions ARM. Cependant, il indique également que la prélecture est un tampon "double 32 bits" qui "optimise les accès 16 bits" qui est le plus approprié pour "s'exécuter en mode Thumb", ce qui semble indiquer qu'il n'est pas destiné à accélérer Instructions ARM, mais pour permettre à votre cœur de fonctionner plus rapidement en mode THUMB.
D'après les diagrammes, il semble que le flash de votre puce dispose en fait d'un bus de données 32 bits. Le préfeteur semble fonctionner en lisant un total de 32 bits, en donnant 16 au processeur (en mode THUMB) et en mettant en cache l'ensemble des 32 bits. Au cours du cycle suivant, lorsque le CPU lit les 16 bits suivants, cette fois dans le cache, le contrôleur flash lit les 32 bits suivants et les met en cache. De cette façon, le code THUMB peut s'exécuter sans plus d'une attente initiale, même si la vitesse du flash serait un peu plus lente que la vitesse du cœur du processeur. La section 19.2.2 «Opérations de lecture» contient plus de détails.
Étant donné que votre flash est un bus 32 bits (pour autant que je sache), si vos horloges CPU et Flash sont identiques, THUMB ne vous donnera que la densité de code sur ARM. Si vous voulez que votre cœur de processeur s'exécute plus rapidement que Flash (et notez, je n'ai pas examiné tout le timing de cette puce; je suppose que le processeur peut fonctionner plus rapidement car ils vous permettent de définir des états d'attente), alors la prélecture donne une vitesse avantage à THUMB en raison de la réduction des accès flash réels. Cependant, cet avantage de vitesse est un avantage par instruction. Si le nombre d'instructions THUMB par rapport aux instructions ARM est suffisamment grand, il dépassera la vitesse par instruction, ce qui donnera à ARM une vitesse par routine plus rapide.