We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
why Program Counter (PC) in debugger shows 0x00000004 instead of 0x0000000C
Becaust that is the value of the PC at that point. Whether or not there's a pipeline containing other instructions currently being prepared for later execution is irrelevant as far as simulating the code's actual behaviour is concerned.
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.