understanding the addressing offset in ASM

Question

im coming from this question

the second answer has the following code:

> arm-none-eabi-gcc -march=armv6-m \
                    -mcpu=cortex-m0 \
                    -mthumb \
                    -Os \
                    -c \
                    -o test.o \
                    test.c

> arm-none-eabi-objdump -dr test.o

00000000 <queue_empty>:
 0: 4b03     ldr   r3, [pc, #12]   ; (10 <queue_empty+0x10>)
 2: 6818     ldr   r0, [r3, #0]
 4: 685b     ldr   r3, [r3, #4]
 6: 1ac0     subs  r0, r0, r3
 8: 4243     negs  r3, r0
 a: 4158     adcs  r0, r3
 c: 4770     bx    lr
 e: 46c0     nop                   ; (mov r8, r8)
10: 00000000 .word 0x00000000
             10: R_ARM_ABS32 .bss

> arm-none-eabi-nm -S test.o

00000000 00000004 b head
00000000 00000014 T queue_empty
00000004 00000004 b tail

Q1:

the first instruction is ldr r3, [pc, #12]

pc register is program counter should have the next instruction address which is (0x2) + offset #12

this will be #14 or 0xE ...

how its commented to be 0x10 ?

Q2: we are loading the value from memory address () to R3 which i can see here : 10: 00000000 .word 0x00000000 is equal to 0. R3 = 0.

then we load the value in address in R3 (which is 0x0). isnt that : same address of the function it self?

0: 4b03 ldr r3, [pc, #12] ; (10 <queue_empty+0x10>)
-^ this address 0

Q3: wouldn't it be faster and smaller code to load data directly because this bss section are already in small memory values already right?

See: -msingle-pic-base, -mpic-data-is-text-relative and -mpic-data-is-text-relative. The ARM addressing modes has no absolute addressing; you must load a constant into a registers first. See: [arm constants blog](https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/how-to-load-constants-in-assembly-for-arm-architecture) Also, [static shared libraries](https://stackoverflow.com/questions/25172834/how-to-create-static-linked-shared-libraries). While the answer below is a duplicate, I think your Q/A is more how not to use constants..esp Q3. — artless noise, Oct 12 '19 at 16:54
See: [Cortex-M and busybox](https://stackoverflow.com/questions/57353552/whats-the-point-of-using-busybox-in-a-low-ram-embedded-system) where some of these addressing considerations come into play with poor system performance due to Cortex-M and a Linux infra-structure which may assume an MMU system for performance but still work (poorly) without one. A system accommodating addressing with 'PIC base' will work much better on a Cortex-M. — artless noise, Oct 12 '19 at 16:59
One solution, dedicate R9 to 'static base', point to DTCM on boot and setup the linker file and boot code to make this happen. You can also plug in context switches where R9 will change and re-use '.text'; part of 'static shared libraries' above. — artless noise, Oct 12 '19 at 17:03

score 1 · Answer 1 · answered Oct 10 '19 at 08:34

1

The pc is two steps ahead of the current instruction execution (hence 4, not 2)
The value 0 gets replaced at link time. It's probably a global variable defined in a different file. (pointer to a structure)
see 2

answered Oct 10 '19 at 08:34

Jake 'Alquimista' LEE

6,197
2
17
25

1. so the next executing instructing is = PC - 2 ? because PC is pointing to the next of the next instruction? .. – Hasan alattar Oct 10 '19 at 08:43
@Hasanalattar That's correct. – Jake 'Alquimista' LEE Oct 10 '19 at 08:44
3. sorry my question isnt clear, why linker doesnt use direct addressing mode since most bss data are in small memory we can address them in small addresses (not 32bit) .. so (ldr direct to memory address) ... – Hasan alattar Oct 10 '19 at 08:44
@Hasanalattar Because it's a **variable**. – Jake 'Alquimista' LEE Oct 10 '19 at 08:46
from what i understand it would be **variable address** for stack based variables not globals and constants (.bss + data) ? – Hasan alattar Oct 10 '19 at 08:48

understanding the addressing offset in ASM

1 Answers1