在 ARM/THUMB 状态之间切换
当异常发生时，为什么 ARM 控制器要从 THUMB 状态返回到 ARM 状态？
Why should an ARM controller return to ARM state from THUMB state, when an exception occurs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一种解释可能是 ARM 模式是 CPU 的“本机”操作模式，并且在该模式下可以比在有限的 Thumb 模式下执行更多操作。据我所知，Thumb 模式针对代码大小进行了优化，这可能意味着它缺少异常处理中可能必需的某些指令。
此页提到异常处理始终在 ARM 模式下完成。它没有提供任何原因，所以也许这只是设计的方式。它确实讨论了从异常处理退出回到正确（ARM 或 Thumb）模式的方法，因此只要您不自己编写异常处理程序，您就可以忽略此问题。当然，假设您的系统设置了一个保留执行模式的“默认”异常处理程序。
另一方面，本页介绍了 Cortex-M3 ARM 实现的中断向量：
所以这似乎并不普遍正确，也许您可以使您的特定异常在 Thumb 模式下运行。
One explanation might be that ARM mode is the CPU's "native" operating mode, and that it's possible to do more operations in that mode than in the limited Thumb mode. The Thumb mode, as far as I've understood, is optimized for code size, which might mean it lacks certain instructions that perhaps are necessary in exception processing.
This page mentions that exception processing is always done in ARM mode. It doesn't provide any reasons why, so maybe it's just The Way It Is, by design. It does talk about ways to exit from exception processing back to the proper (ARM or Thumb) mode though, so as long as you're not writing the exception handler yourself, you might be able to ignore this issue. That, of course, assumes that your system is set up with a "default" exception handler that does retain the execution mode.
On the other hand, this page says this, about the interrupt vectors of the Cortex-M3 ARM implementation:
So it doesn't seem to be universally true, perhaps you can make your particular exception run in Thumb mode.
也许是因为中断向量表实际上是一条ARM指令，并且处理它需要处于ARM模式。这减少了程序员的工作量，因为您不必编写两个处理程序，一个用于手臂模式，一个用于拇指模式。您如何知道异常有一个入口点，并且您只能使用一种指令类型来处理它。一旦进入，您当然可以切换到拇指模式，这与重置异常后切换到拇指模式没有什么不同。
cortex-m3 重新定义了更传统的中断向量表（地址而不是指令）。我必须假设，cortex-m3 是一个仅拇指（2）的处理器，因此它们要么重新定义向量表来保存拇指指令，要么重新定义带有地址的表，或者它们只有足够的 Arm 核心处理您通常在向量表条目中看到的加载或跳转。
基本上，每个异常需要两个条目，一个用于基于手臂的处理程序，一个用于基于拇指的处理程序，或者您要求用户使用专门针对一种模式的入口点编写其处理程序。
即使处理程序使用单模式入口点，您仍然必须了解异常发生时处理器所处的模式，以了解要返回到哪个地址以及如何检查导致异常的相关指令。
Perhaps it is because that the interrupt vector table is really an ARM instruction and to process it requires being in ARM mode. This reduces the programmers job as you dont have to write two handlers one for arm mode and one for thumb mode. How would you even know there is one entry point for an exception and you can only have one instruction type to handle it. You can certainly switch to thumb mode once entered no different than switching to thumb mode after a reset exception.
The cortex-m3 has re-defined the interrupt vector table to be more traditional (an address instead of an instruction). By necessity I would assume, the cortex-m3 is a thumb(2) only processor so either they re-define the vector table to hold thumb instructions or they re-define the table with addresses, or they have just enough of an arm core to process the load or jump that you normally see in a vector table entry.
Basically you would either need two entries per exception, one for the arm based handler and one for the thumb based handler or you require the user to write their handler with an entry point that is one mode specifically.
Even with the one mode entry point into a handler, you still have to be aware of the mode the processor was in when the exception occurred to know what address to return to and how to inspect the instruction in question that caused the exception.
这取决于您拥有哪个 CPU，因为有两个拇指指令集。原始的thumb指令集（用于armv4t、armv5te）缺乏能够处理中断的指令；较新的thumb2集（在皮质系列中）具有额外的指令，因此您可以保持在thumb2模式下以服务中断例程。
It depends which CPU you have, as there are two thumb instruction sets. The original thumb instruction set (used in armv4t, armv5te) lacked instructions to be able to deal with interrupts; the newer thumb2 set (in the cortex series) has extra instructions so you can remain in thumb2 mode to service an interrupt routine.
传统的ARM系统启动进入ARM模式，复位后跳转到复位异常向量。这意味着所有异常向量都必须用 ARM 汇编语言编写。如果你的异常是 ARM 指令，CPU 自然会在异常处理之前被迫将其模式更改为 ARM 模式；如果这种情况没有发生，将导致未定义的异常，这将导致另一个异常，依此类推，陷入无限循环。
最初的ARM系统只有ARM指令，后来添加了THUMB指令；这可能是另一种解释。
Traditional ARM systems boot into ARM mode and jumps to reset exception vector after reset. This means that all exception vectors have to be written in ARM assembly. If your exceptions are ARM instructions naturally the CPU is forced to change its mode to ARM mode before exception handling; if this does not happen it will result in an undefined exception, which will cause another one and so on and on in an infinite loop.
Initial ARM systems only had ARM instructions, the THUMB instructions were later added on; this might be another explanation.