ARM Program Status Register

1
votes

I am currently doing work with the Cortex-M3 and am having trouble understanding the use of the xPSR. I am not sure why the ISR number is stored in lowest 8 bits.

Online sources and datasheets give no clue to why the number must be stored in the xPSR. On the ARM7-TDMI the current mode (FIQ, IRQ, SVC, USR, ABT, UND) is stored in the lowest 8 bits of the CPSR. I assume it is stored there so when an exception is raised and the mode is switched the processor knows which bank of registers to save the state of the CPSR to. However the Cortex-M3 doesn't have banked registers and the xPSR is saved onto the stack when an ISR is needed to be serviced.

Can anyone enlighten me?

2
armcortex-m3
Where are you seeing this? I dont see a cpsr in the armv7m, I see an APSR and with respect to exceptions xPSR is put on the stack to preserve the flags of the code running that was interrupted (not uncommon, that or software has to do it). - old_timer
Sorry I had gotten the terminology wrong in my question. The Current Program Status Register is present on the ARM7-TDMI and is saved to the appropriate Saved Program Status Register depending on the current mode of operation. However my question is why on the Cortex-M3 is the ISR number present in the xPSR. - user2476983

2 Answers

2
votes

Is this what you are talking about?

The IPSR
The processor writes to the IPSR on exception entry and exit. Software can use an MRS instruction, to read
the IPSR, but the processor ignores writes to the IPSR by an MSR instruction. The IPSR Exception Number
field is defined as follows:
•    in Thread mode, the value is 0
•    in Handler mode, holds the exception number of the currently-executing exception.
An exception number indicates the currently executing exception and its entry vector, see Exception number
definition on page B1-633 and The vector table on page B1-634.
On reset, the processor is in Thread mode and the Exception Number field of the IPSR is cleared to 0. As a
result, the value 1, the exception number for reset, is a transitory value, that software cannot see as a valid
IPSR Exception Number.

I would see that as similar to the cpsr in the ARMv4/ARM7TDMI as it gives you the state in which you are executing. if you are executing in an exception and if so which one. It likely has meaning to the chip designers for similar reasons and that is where that information or a copy of that information is held. Perhaps to not re-enter an exception handler if already in that exception mode for example. Or if a second exception of some type, say a prefetch abort while executing the prefetch abort perhaps the processor hangs on purpose or chooses a different exception.

0
votes

Well, I'm not entirely sure I understand the question - are you asking "why is it different" or "what is the point"?

In the first case - the answer is the same as for "why does it not support the ARM instruction set", "why are there only 2 execution modes", "why is the vector table huge and contains addresses rather than instructions" and "why are there only 2 possible stack pointers": "because". Because the M-profile has a completely different exception model. (And because the exception model is different, what was the mode bits in the CPSR was free to use for something else.)

In the second case ... well, that's up to the developer, isn't it? There happens to be a register that holds the currently active interrupt ID. If this is of benefit to you, do use it. You could (for example) use it to have a single interrupt handler address stored into multiple locations in the vector table and then use the interrupt ID to identify which specific device had triggered the interrupt.

It also sounds handy from the point of view of reentrant exception handling.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDBIBGJ.html