Which Of The Following Is Being Used When Loading A Constant Into A Register:

ARM uses a load-shop model for memory admission which means that only load/store (LDR and STR) instructions can access memory. While on x86 virtually instructions are allowed to directly operate on data in memory, on ARM data must exist moved from memory into registers before beingness operated on. This means that incrementing a 32-bit value at a particular retentivity address on ARM would require 3 types of instructions (load, increase, and store) to first load the value at a particular accost into a register, increment it inside the annals, and store it back to the retentivity from the register.

To explain the fundamentals of Load and Store operations on ARM, nosotros start with a basic example and continue with three basic offset forms with 3 different address modes for each kickoff form. For each case we will use the same slice of associates code with a different LDR/STR kickoff form, to keep it unproblematic. The best way to follow this part of the tutorial is to run the code examples in a debugger (GDB) on your lab surroundings.

Kickoff class: Immediate value as the starting time
- Addressing style: Offset
- Addressing mode: Pre-indexed
- Addressing mode: Post-indexed
Outset form: Register equally the showtime
- Addressing mode: Offset
- Addressing mode: Pre-indexed
- Addressing way: Post-indexed
Offset course: Scaled register as the starting time
- Addressing mode: Offset
- Addressing mode: Pre-indexed
- Addressing style: Postal service-indexed

Offset basic example

Generally, LDR is used to load something from memory into a register, and STR is used to store something from a register to a memory address.

LDR R2, [R0]   @ [R0] - origin address is the value found in R0. STR R2, [R1]   @ [R1] - destination accost is the value found in R1.

LDR operation: loads thevalue at the address plant in R0 to the destination annals R2.

STR performance: stores the value constitute in R2 to the memory address plant in R1.

This is how it would await like in a functional assembly program:

.data          /* the .data section is dynamically created and its addresses cannot be easily predicted */ var1: .word iii  /* variable 1 in retention */ var2: .word 4  /* variable ii in retentiveness */  .text          /* start of the text (code) section */  .global _start  _start:     ldr r0, adr_var1  @ load the retention address of var1 via characterization adr_var1 into R0      ldr r1, adr_var2  @ load the retention accost of var2 via label adr_var2 into R1      ldr r2, [r0]      @ load the value (0x03) at memory accost found in R0 to register R2       str r2, [r1]      @ shop the value found in R2 (0x03) to the memory accost found in R1      bkpt               adr_var1: .discussion var1  /* address to var1 stored here */ adr_var2: .word var2  /* accost to var2 stored here */

At the bottom we accept our Literal Pool (a retentiveness surface area in the same code department to store constants, strings, or offsets that others can reference in a position-independent manner) where nosotros store the retentiveness addresses of var1 and var2 (divers in the data section at the top) using the labels adr_var1 and adr_var2. The first LDR loads the address of var1 into register R0. The 2nd LDR does the aforementioned for var2 and loads it to R1. Then we load the value stored at the retentiveness address establish in R0 to R2, and store the value found in R2 to the memory address found in R1.

When we load something into a register, the brackets ([ ]) hateful: the value institute in the annals between these brackets is a memory accost nosotros want to load something from.

When nosotros store something to a memory location, the brackets ([ ]) mean: the value found in the register betwixt these brackets is a memory accost we desire to store something to.

This sounds more complicated than it really is, and so hither is a visual representation of what's going on with the retention and the registers when executing the code above in a debugger:

Let's look at the same code in a debugger.

                      gef>                    detach _start Dump of assembler code for part _start:  0x00008074 <+0>:      ldr  r0,          [pc, #12]          ; 0x8088 <adr_var1>  0x00008078 <+iv>:      ldr  r1,          [pc, #12]          ; 0x808c <adr_var2>  0x0000807c <+eight>:      ldr  r2, [r0]  0x00008080 <+12>:     str  r2, [r1]  0x00008084 <+16>:     bx   lr Finish of assembler dump.

The labels we specified with the first two LDR operations changed to [pc, #12]. This is called PC-relative addressing. Because we used labels, the compiler calculated the location of our values specified in the Literal Pool (PC+12). You can either summate the location yourself using this verbal approach, or you can utilise labels like we did previously. The but difference is that instead of using labels, you demand to count the verbal position of your value in the Literal Puddle. In this case, it is three hops (four+4+4=12) abroad from the effective PC position. More than almost PC-relative addressing later in this affiliate.

Side note: In case you forgot why the effective PC is located two instructions ahead of the current one, information technology is described in Part 2 [… During execution, PC stores the address of the current instruction plus 8 (ii ARM instructions) in ARM state, and the current instruction plus 4 (two Thumb instructions) in Thumb land. This is different from x86 where PC always points to the next educational activity to be executed…].

1.Offset form: Immediate value every bit the starting time

STR    Ra, [Rb,          imm] LDR    Ra, [Rc,          imm]

Hither we apply an firsthand (integer) as an starting time. This value is added or subtracted from the base register (R1 in the example below) to access data at an first known at compile fourth dimension.

.information var1: .give-and-take three var2: .word 4  .text .global _start  _start:     ldr r0, adr_var1  @ load the memory accost of var1 via characterization adr_var1 into R0     ldr r1, adr_var2  @ load the retentiveness address of var2 via label adr_var2 into R1     ldr r2, [r0]      @ load the value (0x03) at memory address institute in R0 to register R2                      str r2, [r1, #2]                      @ address mode: offset. Shop the value found in R2 (0x03) to the retentiveness address found in          R1 plus 2. Base of operations annals (R1) unmodified.                                                    str r2, [r1, #four]!                      @ accost fashion: pre-indexed. Store the value found in R2 (0x03) to the memory address establish in          R1 plus iv. Base annals (R1) modified: R1 = R1+iv                                    ldr r3, [r1]            , #4                    @ accost style: mail service-indexed. Load the value at memory accost found in R1 to register          R3. Base register (R1) modified: R1 = R1+iv      bkpt  adr_var1: .word var1 adr_var2: .word var2

Let's telephone call this plan ldr.s, compile information technology and run information technology in GDB to see what happens.

$ every bit ldr.s -o ldr.o $ ld ldr.o -o ldr $ gdb ldr

In GDB (with gef) nosotros ready a intermission point at _start and run the program.

                      global environment facility>                    break _start                      gef>                    run ...                      gef>                    nexti three     /* to run the next 3 instructions */

The registers on my system are now filled with the post-obit values (keep in mind that these addresses might be different on your organisation):

$r0 :          0x00010098          -> 0x00000003 $r1 :          0x0001009c          -> 0x00000004 $r2 :          0x00000003          $r3 : 0x00000000 $r4 : 0x00000000 $r5 : 0x00000000 $r6 : 0x00000000 $r7 : 0x00000000 $r8 : 0x00000000 $r9 : 0x00000000 $r10 : 0x00000000 $r11 : 0x00000000 $r12 : 0x00000000 $sp : 0xbefff7e0 -> 0x00000001 $lr : 0x00000000 $pc : 0x00010080 -> <_start+12> str r2, [r1] $cpsr : 0x00000010

The adjacent instruction that will exist executed a STR functioning with the offset address mode . Information technology will store the value from R2 (0x00000003) to the memory address specified in R1 (0x0001009c) + the offset (#2) = 0x1009e.

                      gef>                    nexti                      gef>                      x/due west 0x1009e  0x1009e <var2+2>: 0x3

The side by side STR operation uses the pre-indexed address mode . You can recognize this mode by the exclamation mark (!). The only difference is that the base register will be updated with the final memory address in which the value of R2 volition be stored. This means, we shop the value found in R2 (0x3) to the memory address specified in R1 (0x1009c) + the offset (#4) = 0x100A0, and update R1 with this verbal accost.

                      gef>                      nexti                          global environment facility>                    x/w 0x100A0 0x100a0: 0x3                      global environment facility>                    info register r1 r1          0x100a0          65696

The last LDR operation uses the postal service-indexed accost mode . This means that the base register (R1) is used as the final address, then updated with the offset calculated with R1+iv. In other words, it takes the value institute in R1 (not R1+4), which is 0x100A0 and loads it into R3, then updates R1 to R1 (0x100A0) + starting time (#four) = 0x100a4.

                      gef>                    info register r1 r1          0x100a4          65700                      gef>                    info register r3 r3          0x3          three

Here is an abstruse illustration of what's happening:

2.Outset form: Register as the offset.

STR    Ra, [Rb,          Rc] LDR    Ra, [Rb,          Rc]

This offset course uses a register as an offset. An instance usage of this outset grade is when your code wants to access an assortment where the index is computed at run-time.

.information var1: .give-and-take 3 var2: .discussion 4  .text .global _start  _start:     ldr r0, adr_var1  @ load the memory accost of var1 via label adr_var1 to R0      ldr r1, adr_var2  @ load the memory accost of var2 via label adr_var2 to R1      ldr r2, [r0]      @ load the value (0x03) at memory accost found in R0 to R2                                    str r2, [r1, r2]                      @ address manner: offset. Store the value found in R2 (0x03) to the memory address constitute in R1 with the start R2 (0x03). Base register unmodified.                                    str r2, [r1, r2]!                      @ address mode: pre-indexed. Store value found in R2 (0x03) to the memory address found in R1 with the kickoff R2 (0x03). Base of operations annals modified: R1 = R1+R2.                      ldr r3, [r1], r2                                @ accost mode: post-indexed. Load value at retention address plant in R1 to register R3. Then modify base annals: R1 = R1+R2.     bx lr  adr_var1: .give-and-take var1 adr_var2: .give-and-take var2

After executing the first STR performance with the get-go address mode , the value of R2 (0x00000003) will be stored at memory address 0x0001009c + 0x00000003 = 0x0001009F.

                      gef>                    x/westward 0x0001009F  0x1009f <var2+3>: 0x00000003

The second STR performance with the pre-indexed address style will do the same, with the difference that it volition update the base register (R1) with the calculated retentivity address (R1+R2).

                      gef>                    info register r1  r10x1009f          65695

The last LDR operation uses the mail-indexed address manner and loads the value at the retention address found in R1 into the register R2, then updates the base register R1 (R1+R2 = 0x1009f + 0x3 = 0x100a2).

                      gef>                    info annals r1  r1          0x100a2          65698                      gef>                    info annals r3  r30x3          3

3.Offset course: Scaled register as the offset

LDR    Ra, [Rb,          Rc, <shifter>] STR    Ra, [Rb,          Rc, <shifter>]

The third offset course has a scaled annals as the showtime. In this case, Rb is the base register and Rc is an immediate beginning (or a register containing an immediate value) left/right shifted (<shifter>) to scale the immediate. This means that the barrel shifter is used to scale the offset. An example usage of this showtime course would be for loops to iterate over an array. Here is a simple instance you tin run in GDB:

.data var1: .word 3 var2: .word 4  .text .global _start  _start:     ldr r0, adr_var1         @ load the memory address of var1 via label adr_var1 to R0     ldr r1, adr_var2         @ load the memory accost of var2 via label adr_var2 to R1     ldr r2, [r0]             @ load the value (0x03) at retention accost found in R0 to R2                      str r2, [r1, r2, LSL#2]                                @ address mode: beginning. Store the value found in R2 (0x03) to the memory address constitute in R1 with the offset R2 left-shifted by 2. Base register (R1) unmodified.                      str r2, [r1, r2, LSL#2]!                      @ address mode: pre-indexed. Store the value constitute in R2 (0x03) to the retentivity accost constitute in R1 with the offset R2 left-shifted by 2. Base register modified: R1 = R1 + R2<<2                                    ldr r3, [r1], r2, LSL#2                                @ address way: post-indexed. Load value at memory address found in R1 to the register R3. So modifiy base register: R1 = R1 + R2<<2     bkpt  adr_var1: .discussion var1 adr_var2: .word var2

The offset STR operation uses the offset address way and stores the value constitute in R2 at the memory location calculated from [r1, r2, LSL#two], which means that it takes the value in R1 every bit a base of operations (in this case, R1 contains the memory address of var2), then it takes the value in R2 (0x3), and shifts it left by 2. The picture below is an attempt to visualize how the retentivity location is calculated with [r1, r2, LSL#2].

The second STR operation uses the pre-indexed accost fashion . This means, information technology performs the same action every bit the previous operation, with the departure that it updates the base register R1 with the calculated memory address after. In other words, it will first store the value constitute at the retentiveness address R1 (0x1009c) + the starting time left shifted past #2 (0x03 LSL#ii = 0xC) = 0x100a8, and update R1 with 0x100a8.

                      gef>                    info annals r1 r1           0x100a8          65704

The concluding LDR operation uses the post-indexed address mode . This means, information technology loads the value at the retentivity address institute in R1 (0x100a8) into register R3, so updates the base register R1 with the value calculated with r2, LSL#2. In other words, R1 gets updated with the value R1 (0x100a8) + the offset R2 (0x3) left shifted by #2 (0xC) = 0x100b4.

                      gef>                    info register r1 r10x100b4          65716

Summary

Recollect the three offset modes in LDR/STR:

showtime mode uses an immediate equally first
- ldr r3, [r1, #4]
offset manner uses a register as start
- ldr r3, [r1, r2]
offset mode uses a scaled register every bit offset
- ldr r3, [r1, r2, LSL#two]

How to remember the different address modes in LDR/STR:

If in that location is a !, it's prefix accost mode
- ldr r3, [r1, #4]!
- ldr r3, [r1, r2]!
- ldr r3, [r1, r2, LSL#2]!
If the base annals is in brackets by itself, it's postfix accost mode
- ldr r3, [r1], #four
- ldr r3, [r1], r2
- ldr r3, [r1], r2, LSL#2
Annihilation else is offset address mode.
- ldr r3, [r1, #four]
- ldr r3, [r1, r2]
- ldr r3, [r1, r2, LSL#2]

LDR is non simply used to load data from retentivity into a register. Sometimes you lot will come across syntax like this:

.department .text .global _start  _start:    ldr r0, =jump        /* load the address of the function label jump into R0 */    ldr r1, =0x68DB00AD  /* load the value 0x68DB00AD into R1 */ spring:    ldr r2, =511         /* load the value 511 into R2 */     bkpt

These instructions are technically chosen pseudo-instructions. We tin apply this syntax to reference information in the literal pool. The literal pool is a retentiveness area in the same section (because the literal puddle is part of the code) to shop constants, strings, or offsets. In the example higher up we utilize these pseudo-instructions to reference an offset to a function, and to move a 32-bit constant into a register in 1 instruction. The reason why nosotros sometimes need to use this syntax to move a 32-bit constant into a annals in one educational activity is because ARM can only load a 8-bit value in one become. What? To sympathize why, y'all need to know how immediate values are existence handled on ARM.

Loading immediate values in a register on ARM is not as straightforward every bit it is on x86. There are restrictions on which immediate values you can apply. What these restrictions are and how to deal with them isn't the most heady part of ARM assembly, only acquit with me, this is merely for your understanding and in that location are tricks you can use to bypass these restrictions (hint: LDR).

We know that each ARM instruction is 32bit long, and all instructions are conditional. There are xvi status codes which we can use and one status code takes up 4 bits of the instruction. Then we demand ii bits for the destination register. 2 bits for the outset operand register, and 1 chip for the set-condition flag, plus an assorted number of bits for other matters like the actual opcodes. The point hither is, that later assigning bits to instruction-type, registers, and other fields, there are but 12 bits left for firsthand values, which volition just allow for 4096 unlike values.

This means that the ARM instruction is only able to utilize a express range of firsthand values with MOV directly. If a number tin't be used directly, it must be separate into parts and pieced together from multiple smaller numbers.

But at that place is more. Instead of taking the 12 bits for a single integer, those 12 bits are carve up into an 8bit number (n) being able to load whatever eight-bit value in the range of 0-255, and a 4bit rotation field (r) being a right rotate in steps of two between 0 and xxx. This means that the full immediate value v is given by the formula: v = n ror 2*r. In other words, the only valid immediate values are rotated bytes (values that can exist reduced to a byte rotated past an fifty-fifty number).

Here are some examples of valid and invalid immediate values:

Valid values: #256        // 1 ror 24 --> 256 #384        // 6 ror 26 --> 384 #484        // 121 ror 30 --> 484 #16384      // 1 ror 18 --> 16384 #2030043136 // 121 ror 8 --> 2030043136 #0x06000000 // 6 ror 8 --> 100663296 (0x06000000 in hex)  Invalid values: #370        // 185 ror          31 -->                      31 is not in range (0 – 30)          #511        // 1 1111 1111          --> scrap-pattern tin't fit into 1 byte #0x06010000 // 1 k 000i.. --> bit-blueprint can't fit into i byte

This has the consequence that information technology is not possible to load a full 32bit accost in one go. We can bypass this restrictions by using 1 of the following 2 options:

Construct a larger value out of smaller parts
1. Instead of using MOV r0, #511
2. Split 511 into two parts: MOV r0, #256, and Add together r0, #255
Utilise a load construct 'ldr r1,=value' which the assembler volition happily convert into a MOV, or a PC-relative load if that is not possible.
1. LDR r1, =511

If you try to load an invalid immediate value the assembler will complain and output an error saying: Fault: invalid abiding. If yous come across this error, you now know what it means and what to exercise virtually it.
Let's say you lot desire to load #511 into R0.

.section .text .global _start  _start:     mov     r0, #511     bkpt

If you endeavour to assemble this code, the assembler will throw an error:

azeria@labs:~$ equally test.s -o test.o test.s: Assembler messages: test.southward:5: Mistake: invalid constant (1ff) after fixup

You need to either split 511 in multiple parts or you apply LDR equally I described before.

.section .text .global _start  _start:  mov r0, #256   /* 1 ror 24 = 256, so it's valid */  add r0, #255   /* 255 ror 0 = 255, valid. r0 = 256 + 255 = 511 */  ldr r1, =511   /* load 511 from the literal pool using LDR */  bkpt

If you lot need to figure out if a sure number tin can be used as a valid immediate value, yous don't need to summate it yourself. You can use my niggling python script called rotator.py which takes your number as an input and tells you if it can be used equally a valid immediate number.

azeria@labs:~$ python rotator.py Enter the value yous want to check: 511  Deplorable, 511 cannot be used equally an immediate number and has to be split.  azeria@labs:~$ python rotator.py Enter the value y'all want to check: 256  The number 256 can be used as a valid firsthand number. 1 ror 24 --> 256