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.
View all questions in Keil forum