tools/capdis -v -s='0xffab8cf0' -c=42 -stubs=platform/ixus160_elph160/sub/100a/ -d ../ixus160/PRIMARY.BIN 0xff810000then I go thru ARM instructions and operands. Match up ARM instructions to the reference manual. I think I have the PUSH decoded correctly. The next instruction is

# LDR <Rd>, [PC, #<immed_8> * 4]# Rd is dest register, # pc is program counter, used to calc mem addr; # Bit 1 of pc val forced to 0 for this calc,# such that addr (results?) is word-aligned.# immed_8 is 8bit val * 4 and added to PC to form mem addr

It must be related, due to Rd = (0xffab8ebc) ... I suspect this, because loc_ffab8eac !!! It's the address written to 7 (jpg) chunk times <from hdr file>. Also suspect this because ldr3 is the only ldr instruction in the ref mentioning PC.

Everything after the ; is a comment, describing how the preceding instruction actually gets 0x0000b584 into r5.

When you do ldr rx, =blah

You are actually telling the assembler to generate PC relative load (as described in the documentation you quoted), and store to the 0x... constant somewhere nearby.

So the [pc, #448] means the assembler decided to put the constant at the current address +448 (subject to some details), and the (0xffab8ebc) is the resulting physical address of PC+448. So if you looked at address 0xffab8ebc (e.g. using rmem in chdkptp), you should see the constant 0x0000b584 there.

The "nearby" part is why our inline assembly is littered with .ltorg directives, because you need to tell the assembler where it can put these things.