I am a newbie to ARM and KEIL, I wrote a samll program in assembly and try to simulate it using debuger, I noticed that the PC value is same as the line which is just executed (i.e. marked with green rectangle) but because the arm uses 3 stage pipe line I was expecting to see PC is 8 Byte ahead to the line which is executed. folowing is the code.
GLOBAL Reset_Handler AREA Reset,CODE,READONLY ENTRY Reset_Handler MOV R0,#0x11 MOV R1,R0,LSL#1 MOV R2,R1,LSL#1 STOP B STOP
END
Do you believe that, or can you produce any actual documentation for that claim?
I have seen a number of references that clearly says that PC points at the fetched instruction - not the executed instruction.
And looking at the output from the assembler, a jump of PC+0 is a jump two steps forward, while it takes pc - 2 (i.e. PC - 8 bytes) to get an empty, infinite loop.
So when the debugger is about to execute an instruction that makes a jump to PC-2, it would be reasonable that the debugger then actually show a contents of PC that is the fetched instruction two steps forward. Or else that -2 will nto make sense.
Thanks for all your post on my question,
I tested debugger by LDR PC,[PC,#4] as you can see in following code and it worked they way that if it was in thumb state (but T in CPSR was 0).
5: MOV R0,#0x11 0x00000000 E3A00011 MOV R0,#0x00000011 6: LDR PC,[PC,#4] 0x00000004 E59FF004 LDR PC,[PC,#0x0004] 7: MOV R1,R0,LSL#1 0x00000008 E1A01080 MOV R1,R0,LSL #1 8: MOV R2,R1,LSL#1 0x0000000C E1A02081 MOV R2,R1,LSL #1 9: STOP B STOP 0x00000010 EAFFFFFE B 0x00000010
After executing line 6 it jumped to line 8, which means the PC was 0x00000008 rather than being 0x0000000C.
This could be the case if ARM is in THUMB state, but not in ARM state.