LDR R1,=address
Is pseudocode. worst case it results in a pc-relative load with the value in a pool nearby. That is if it is supported at all. Assembly is defined by the assembler not the target, the tool not the instruction set. And with this pseudo code in particular it is handled differently some don't support it at all some I would assume are always pc-relative and gnu its the ideal mov reg,immediate solution because it will optimize it into a mov, mvn where possible.
Some allow for a value directly, not just a label.
.arm
ldr r0,=my_data_start
ldr r0,=0x1000
ldr r0,=next_data_item
b .
.data
my_data_start: .word 0
next_data_item:
00000000 <.text>:
0: e59f0008 ldr r0, [pc, #8] ; 10 <__data_start-0xff0>
4: e3a00a01 mov r0, #4096 ; 0x1000
8: e59f0004 ldr r0, [pc, #4] ; 14 <__data_start-0xfec>
c: eafffffe b c <__data_start-0xff4>
10: 00001000 andeq r1, r0, r0
14: 00001004 andeq r1, r0, r4
Disassembly of section .data:
00001000 <__data_start>:
1000: 00000000 andeq r0, r0, r0
Clearly your example is not gnu assembler and this example is. But in any case you can see that a pc-relative load was used by this tool when the address was not available at assemble time to be patched in by the linker. How and where you find the pool is up to you. But you can use existing tools for examples and see that it is pc-relative addressing and that is what you fill in for the instruction. But you also have to find a place for that value within that range, and that is specific to you as to how and where you place those values.
The exact encoding for that instruction can and will vary, there is no exact right answer, it depends on where the value is placed as to what the complete encoding is.
Where other instructions like ADD R3,R3,R2 have an exact instruction or perhaps two correct ones.
But BNE loop can vary depending on how much code is between loop and that instruction, as written then the relative offset should be the same from any tool.