Question regarding ARM assembler's LDR instruction and address rounding

oys_mo · ‎2010-12-12

Posted on December 13, 2010 at 05:12

oys_mo · ‎2011-05-17

Posted on May 17, 2011 at 14:18

Hm my version of the document did not even have an A6 7.42 section :S Could you quote the text?

The following code

.syntax unified .cpu cortex-m3 .fpu softvfp .thumb .section .data .align 4 .byte 0x77 var1: .word 0xCAFEBABE @ Memory layout: @ 2000.0000: 77 BE BA FE CA 00 00 00 .section .text .global main .thumb_func main: ldr r0, =var1 @ r0 contains 0x20000001 ldr r1, [r0] @ r1 contains 0xFEBABE77 bx lr

seems to assemble into

00 00 00 00 00 00 00 00 5F F8 E0 F1 01 48 01 68 70 47 00 00 01 00 00 20 00 F0 26 F8 0C 48 80 F3 08 88 00 21 03 E0 0B 4B 5B 58 43 50 04 31 0A 48 0A 4B 42 18 9A 42 F6 D3 09 4A 02 E0 00 23 42 F8 04 3B 08 4B 9A 42 F9 D3 FF F7 E0 FF 70 47 00 00 00 80 00 20 44 02 00 08 00 00 00 20 10 00 00 20 10 00 00 20 10 00 00 20 70 47 FE E7 77 BE BA FE CA 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF

if I'm thinking correctly here. So the first LDR seems to assemble into a 0x0148 (ADR?), and the second to a 0x0168.

oys_mo · ‎2011-05-17

Posted on May 17, 2011 at 14:18

The LDR R1,[R0] was unexpected, as I thought it should rotate, but if you are right, I guess it is behaving normally.

There is nothing unexpected in my original code, as long as one applies the address offset after rounding, which I suppose one does?

.syntax unified .cpu cortex-m3 .fpu softvfp .thumb .section .data .align 2 var1: .word 0xCAFEBABE @ An initialized word in the .data segment, word aligned .section .text .global main .thumb_func main: ldr r0, =var1 ldr r1, [r0] @ r1 now contains 0xCAFEBABE ldr r1, [r0, #3] @ r1 now contains 0xFFFFFFCA bx lr

assembles to

00 00 00 00 00 00 00 00 5F F8 E0 F1 02 48 01 68 D0 F8 03 10 70 47 00 00 00 00 00 20 00 F0 26 F8 0C 48 80 F3 08 88 00 21 03 E0 0B 4B 5B 58 43 50 04 31 0A 48 0A 4B 42 18 9A 42 F6 D3 09 4A 02 E0 00 23 42 F8 04 3B 08 4B 9A 42 F9 D3 FF F7 DE FF 70 47 00 00 00 80 00 20 48 02 00 08 00 00 00 20 04 00 00 20 04 00 00 20 04 00 00 20 70 47 FE E7 BE BA FE CA FF FF FF FF FF FF FF FF FF FF FF FF

where

ldr r0, =var1 becomes ldr r0, [PC, #8] @ code 0x0248 ldr r1, [r0] stays the same @ code 0x0168 ldr r1, [r0, #3] becomes ldr.w r1, [r0, #3] @ code 0xD0F80310

According to my debugger.

oys_mo · ‎2011-05-17

Posted on May 17, 2011 at 14:18

My version of that document does not have that section (it's from 2007).

So the conclusion is that:

#1: Non-aligned memory addresses are rounded down

#2: There is no rotation

#3: Offsets are applied after any rounding

But yeah, I think this thing is solved, case closed. Thanks a lot for your help guys, it's nice to get some answers :)

stforum2 · ‎2011-05-17

Posted on May 17, 2011 at 14:18

ldr r1, [r0, #3]

becomes

ldr.w r1, [r0, #3] @ code 0xD0F80310

Rearrange that to 0XF8D01003 to get the actual byte order

for the opcode and ldr.w r1, [r0, #3] is correct.

Makes sense. Our assembler does the same.

Encoding T3 if you can find the relevant section. Page A6-88 in DDI 0405B.

Pages A6-88 and A6-89 explain it all.

And no rounding:

ldr r1, [r0] @ r1 now contains 0xCAFEBABE

ldr r1, [r0, #3] @ r1 now contains 0xFFFFFFCA