回答:
THUMB命令は、ARM命令よりも本質的に遅いという私の知る限りではなく、機能がより制限されています。コードがTHUMB命令の機能のみを必要とする場合、ARMよりも占有スペースは少なくなりますが、命令の数は同じで、他の条件が同じであれば、同じ速度で実行されます。コードがより多くの機能を必要とする場合、実行するのにARM命令よりも多くのTHUMB命令が必要であり、時間がかかります。他の条件も同じです（以下を参照）
THUMBは、2つの理由で命令のサイズが小さいため、マイクロコントローラーで人気があります。
2番目の理由により、コードがARM命令セットの機能を必要としない場合、THUMBコードは実際により速く実行されます。これは、命令をフラッシュから2回ではなく1回のI / Oサイクルでフェッチできるためです。フラッシュインターフェイスの速度に応じて、2回目の読み取りでは、CPUが単にストールして何も実行できない命令ごとに1つ以上の待機サイクルが発生する可能性があります。
これは、実行前にコードをRAMにコピーできれば問題になりません（最近のARMマイクロコントローラーでは通常32ビットと表示されています）。この場合、唯一の懸念はコード密度です。そのため、多くのツールは、特定の関数に対してどの表現がより効率的かを見つけようとします。コンパイラがTHUMBコードを生成できる命令の数が少ない場合は生成されますが、ARMの結果が生成する命令の数が少ない場合は、ARMになります。正しく思い出せば、これはKeilのデフォルトモードです。
特定のチップ（AT91SAM7S32）の場合、ドキュメントには、フラッシュコントローラーにアクセスを予測して効率を上げることができるプリフェッチバッファーがあり、これによりARM命令の実行が改善される可能性があると記載されています。ただし、プリフェッチは「16ビットアクセスを最適化する」「デュアル32ビット」バッファであり、「Thumbモードでの実行」に最適であり、高速化を意図していないように見えますARM命令。ただし、THUMBモードでコアをより高速に実行できます。
図から、チップのフラッシュには実際には32ビットのデータバスがあるように見えます。プリフェッチャーは、32ビット全体を読み取り、CPUに16を与え（THUMBモード）、32ビット全体をキャッシュすることで機能するようです。次のサイクルで、CPUが2番目の16ビットを読み取るとき、今回はキャッシュから、フラッシュコントローラーが次の32ビットを読み取ってキャッシュしています。このようにして、フラッシュ速度がCPUコア速度より少し遅い場合でも、THUMBコードは最初の待機のみで実行できます。詳細については、19.2.2項「読み取り操作」を参照してください。
フラッシュは32ビットバスであるため（私の知る限り）、CPUクロックとフラッシュクロックが同じ場合、THUMBはARMよりもコード密度が高くなります。CPUコアをフラッシュよりも高速に実行したい場合（および、このチップのすべてのタイミングを確認しなかったことに注意してください。CPUは待機状態を設定できるため、CPUはより高速に実行できると想定しています）、プリフェッチが速度よりも速い実際のフラッシュアクセスの削減によるTHUMBの利点 ただし、その速度の利点は、命令ごとの利点です。THUMB命令とARM命令の数が十分に多い場合は、命令ごとの速度を上回り、ARMのルーチンごとの速度が速くなります。