PC relative load instruction

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the PC relative load what value of the program counter is used to compute the effective address of the value to load into the destination register? The Architecture Document (doc32000.pdf) suggests it is the address of the LDDPC instruction. avr32-gcc might lead you to believe that it was the lda.w (an avr32-as assemblerism for LDDPC) instruction minus two(bytes). A complete description of where in the pipelining process the effective address calculation takes place would be helpful.

We never have time to do it right,
but we always have time to do it over

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Papabravo wrote:
avr32-gcc might lead you to believe that it was the lda.w (an avr32-as assemblerism for LDDPC) instruction minus two(bytes).

Where does it lead you to belive that?
Quote:
A complete description of where in the pipelining process the effective address calculation takes place would be helpful.

PC always contains the address from which the instruction was fetched. In the (special) case of lddpc, the two least significant bits are forced to 0.

lda.w is somewhat more complicated since it's not a real instruction -- the assembler and linker may implement it using one of several instruction sequences depending on assembler/linker flags, type of symbol, distance to target, etc. So if you must know the exact address of the instruction, you should probably avoid lda.w.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was looking at an assembly listing from avr32-as. The input file was generated by avr32-gcc. Decoding the lda.w instuction pointed to a group of zeros after the end of the function, but preceeded by the pseudo operation .cpool. I take that to mean constant pool. I can't consistently make the addition of the PC and the offset get to a location inside the .cpool.

Superficially it looked like lda.w was translated as LDDPC. Now that I understand what lda.w is doing it seems clear that the situation is not resolved until the link is done. In this case the intermediate assembly has some indeterminate values. The same would be true for external sysmbols whose address is not known at assembly time.

We never have time to do it right,
but we always have time to do it over