Question

I’m thinking about this question for a time: when does an ARM7(with 3 pipelines) processor increase its PC register.

I originally thought that after an instruction has been executed, the processor first check is there any exception in the last execution, then increase PC by 2 or 4 depending on current state. If an exception occur, ARM7 will change its running mode, store PC in the LR of current mode and begin to process current exception without modifying the PC register.

But it make no sense when analyzing returning instructions. I can not work out why PC will be assigned LR when returning from an undefined-instruction-exception while LR-4 from prefetch-abort-exception, don’t both of these exceptions happened at the decoding state? What’s more, according to my textbook, PC will always be assigned LR-4 when returning from prefetch-abort-exception no matter what state the processor is(ARM or Thumb) before exception occurs. However, I think PC should be assigned LR-2 if the original state is Thumb, since a Thumb-instruction is 2 bytes long instead of 4 bytes which an ARM-instruction holds, and we just wanna roll-back an instruction in current state. Is there any flaws in my reasoning or something wrong with the textbook.

Seems a long question. I really hope anyone can help me get the right answer.

Thanks in advance.

Answer 1

You return to LR from undefined-instruction handling because that points to the instruction after the one that caused the trap; you don’t want to return to the same undefined instruction again, it’ll only hit the same trap.

You return to LR-4 from prefetch-abort if you want to execute the same instruction again; presumably because you’ve mapped some memory in for it so it’ll now work.

At what point in the pipeline an ARM7 actually increases its PC is irrelevant, because the value of PC during execution and consequently the value of LR in abort handlers is something laid down as part of the ARM architecture standard, based largely on what the ancient ARM2 did with its PC.

However, I think PC should be assigned LR-2 if the original state is Thumb

That would make sense, but then the exception handler would need to know whether the original code that caused it to trigger was ARM or Thumb code. This might have impacted compatibility too, as there was plenty of non-Thumb-aware exception handling code around. So instead the Thumb architecture fudged the LR on entry to exception handlers so that the handler could always use the same instruction to return, the one they were used to using for non-Thumb code.