• Locked Locked
  • Replies 8 replies
  • Subscribers 119 subscribers
  • Views 11528 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Program Counter update

Maya Maya
Note: This was originally posted on 15th June 2009 at http://forums.arm.com

In the Architectural Reference Manual for ARMv7 the PC update is described such that it gets update with adding 8 to the current PC while executing an ARM instruction and adding 4 for Thumb instruction. ARM instructions are 32-bit, hence I'd expect the PC to be updated by adding 4 to it rather than 8. Does anyone knows what is the reason behind this? Am I missing something or is it a mistake?

Thanks
  • Note: This was originally posted on 16th June 2009 at http://forums.arm.com

    The PC increment during "normal execution" will be 4 for ARM, and 2 or 4 for Thumb (depending if if it is a 16 or 32-bit Thumb instruction).


    That's exactly what I expected to see, PC increment of 4 for ARM, and 2 or 4 for Thumb instructions. But on page A2-11 (Section A2.3) of the manual (ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition) it's been said that:

    PC, the Program Counter
    Register R15 is the program counter:
    "¢ When executing an ARM instruction, PC reads as the address of the current
    instruction plus 8.
    "¢ When executing a Thumb instruction, PC reads as the address of the current
    instruction plus 4.
    "¢ Writing an address to PC causes a branch to that address.
    In Thumb code, most instructions cannot access PC.

    Thanks
  • Note: This was originally posted on 16th June 2009 at http://forums.arm.com

    If that's the case, one would expect seeing PC + 6 due to having 16 and 32 bit Thumb instructions. Would that also be possible? How come that's not mentioned?
  • Note: This was originally posted on 25th June 2009 at http://forums.arm.com

    The modern microarchitectures are a lot more complex than the early ARM processors, so the value of PC + 8 for ARM and PC+ 4 for Thumb does not really reflect any feature of the microarchitecture any more, but you have to specify something so software can function in the same ways on all of the different processors and using the existing standard makes most sense (the old software still works).


    So you mean to say that regardless of architecture and whether we have 3 stage or 5 stage or any other kind of pipeline, the value in PC is always Current Instruction address +4 or +8 depending on whether we are in ARM mode or thumb mode ? Doesn't that also mean that it may be risky to do jumps by directly writing into PC like in the good old days because the PC may not exactly point to the instruction being fetched next ??
  • Arm Employee Badge
    Note: This was originally posted on 16th June 2009 at http://forums.arm.com

    Can provide a page number in the ARM ARM so I can be sure what you are talking about?

    The PC increment during "normal execution" will be 4 for ARM, and 2 or 4 for Thumb (depending if if it is a 16 or 32-bit Thumb instruction).

    I think the numbers you are referring to the exception offsets, which are used to calculate the address of the faulting instruction or the address of the instruction to return to after an exception has occurred. For historical reasons these offsets are the sometimes numbers you describe - the full set of offsets is described in Table 10.4. of the ARM ARMv7-AR.
  • Arm Employee Badge
    Note: This was originally posted on 16th June 2009 at http://forums.arm.com

    Ah - welcome to the wonders of a pipelined processor microarchitecture.

    The PC of the instruction being fetched *now* is generally ahead of the PC of the executing instruction *now*, and for historical reasons on the early ARM processors this pipelining effect resulted in the precise offsets you see. If you used PC during an instruction you would will see the "address of the executing instruction +8" - because PC had been incremented twice and the processor was now loading an instruction two ahead of the one being executed.

    The modern microarchitectures are a lot more complex than the early ARM processors, so the value of PC + 8 for ARM and PC+ 4 for Thumb does not really reflect any feature of the microarchitecture any more, but you have to specify something so software can function in the same ways on all of the different processors and using the existing standard makes most sense (the old software still works).
  • Arm Employee Badge
    Note: This was originally posted on 16th June 2009 at http://forums.arm.com

    Any Thumb instruction (whether 16-bit or 32-bit) will always see PC + 4; the hardware stitches up the difference.

    This is one of those areas where modern processor microarchitecture doesn't really match the original design assumptions, but you need some strict definition of what PC is at any point in time to be able to write software =)
  • Note: This was originally posted on 16th June 2009 at http://forums.arm.com

    PC, the Program Counter
    Register R15 is the program counter:
    "¢ When executing an ARM instruction, PC reads as the address of the current
    instruction plus 8.
    "¢ When executing a Thumb instruction, PC reads as the address of the current
    instruction plus 4.
    "¢ Writing an address to PC causes a branch to that address.
    In Thumb code, most instructions cannot access PC.


    This is the value that is returned when the PC is read.  I believe it's largely due to legacy.  When earlier implementations actually executed instructions, the core had already fetched two instructions after it, so the value in PC had already advanced by two instructions worth.
  • Arm Employee Badge
    Note: This was originally posted on 25th June 2009 at http://forums.arm.com

    Correct, the ARM architecture defines the value of the PC read by any particular instruction;
    in addition it precisely defines the behavour of writing to the PC with various instructions,
    thus this isn't "risky". All processor implementations adhering to the ARM architecture must
    make this work, irrespective of their underlying micro-architecture.

    hth
    s.