En general
Las instrucciones THUMB no son intrínsecamente más lentas que las instrucciones ARM, sino que tienen una capacidad más limitada. Si su código solo necesita la funcionalidad de las instrucciones THUMB, ocupará menos espacio que ARM, pero sería la misma cantidad de instrucciones y, en igualdad de condiciones, se ejecutará a la misma velocidad. Si su código necesita más funcionalidad, requeriría más instrucciones THUMB que instrucciones ARM para ejecutarse y tomaría más tiempo, de nuevo otras cosas son iguales (ver más abajo)
THUMB es popular en los microcontroladores debido a las instrucciones de menor tamaño por dos razones:
- El espacio del programa es a menudo limitado
- Muchos microcontroladores tienen buses de datos de 16 bits a su flash interno
Por la segunda razón, cuando su código no requiere funcionalidad del conjunto de instrucciones ARM, el código THUMB en realidad se ejecuta más rápido. Esto se debe a que su instrucción se puede obtener en un ciclo de E / S desde la memoria flash en lugar de dos. Dependiendo de la velocidad de su interfaz flash, esa segunda lectura puede incurrir en uno o más ciclos de espera por instrucción donde su CPU simplemente se detiene y no puede hacer nada.
Esto se convierte en un problema menor si puede copiar su código a la RAM antes de ejecutarlo (lo que generalmente he visto como 32 bits para los microcontroladores ARM recientes), donde la única preocupación es la densidad del código. Para eso, muchas herramientas intentarán encontrar qué representación es más eficiente para una función determinada. Si el compilador puede producir código THUMB en menos instrucciones, lo hará, pero si ARM da como resultado menos instrucciones, obtendrá ARM. Este es el modo predeterminado para Keil, si recuerdo correctamente.
Su chip específico
Para su chip particular (AT91SAM7S32), la documentación menciona que el controlador flash tiene un búfer de captación previa que puede predecir los accesos para hacer las cosas más eficientes, lo que podría mejorar la ejecución de la instrucción ARM. Sin embargo, también indica que la captación previa es un búfer "dual de 32 bits" que "optimiza los accesos de 16 bits", que es más adecuado para "ejecutarse en modo Thumb", lo que parece indicar que no está destinado a acelerar Instrucciones ARM, pero para permitir que su núcleo funcione más rápido en modo THUMB.
Según los diagramas, parece que el flash en su chip en realidad tiene un bus de datos de 32 bits. El prefetcher parece funcionar leyendo 32bits completos, dando 16 a la CPU (en modo THUMB) y almacenando en caché los 32bits completos. Durante el siguiente ciclo, cuando la CPU lee los segundos 16 bits, esta vez desde la memoria caché, el controlador flash está leyendo los siguientes 32 bits y lo almacena en caché. De esta manera, el código THUMB puede ejecutarse sin más que una espera inicial, incluso si la velocidad del flash sería un poco más lenta que la velocidad del núcleo de la CPU. La Sección 19.2.2 "Operaciones de lectura" tiene más detalles.
Dado que su flash es un bus de 32 bits (por lo que puedo decir), si su CPU y sus relojes Flash son iguales, THUMB solo le dará densidad de código sobre ARM. Si desea que el núcleo de su CPU se ejecute más rápido que Flash (y tenga en cuenta que no revisé todos los tiempos de este chip; supongo que la CPU puede funcionar más rápido porque le permiten establecer estados de espera), entonces la captación previa da una velocidad ventaja para THUMB debido a la reducción en los accesos reales de flash. Sin embargo, esa ventaja de velocidad es una ventaja por instrucción. Si el número de instrucciones THUMB vs instrucciones ARM es lo suficientemente grande, superará la velocidad por instrucción, lo que dará como resultado que ARM tenga una velocidad más rápida por rutina.
