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
The program is related to the current instruction - not instructions that may be several steps away in the pipeline. After all - the current instruction could represent a jump, in which case the pipeline would be invalidated.
Thanks for your reply, what I meant to say is , suppose the instruction MOV r0,r1 is located at the address 0x00000004 and just executed, why Program Counter (PC) in debugger shows 0x00000004 instead of 0x0000000C. Because when processor executing an instruction it is decoding the other one and fetching the one after that. but I cannot observe it in debugger.
I'm sorry if I gave you a bad answer.
I did look a bit further and ARM do say that the PC should point to the fetched instruction and not the current instruction. When single-stepping in assembler, I normally don't look at the PC - it's only when I have written trap handlers that I have had to bother with stack frames and PC behaviour to figure out what instruction that caused the exception.
You might have to talk with Keil about this. If they have made a presentation decision because they got too many complaints when the editor showed one instruction as active and the PC indicate another instruction. Or if it is something related to Keils addition of thumb and tumb2 modes.
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.