Ed Lee <edward.ming.lee@gmail.com> wrote:> On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote: > > On 4.5.21 16.32, Ed Lee wrote: > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote: > > >> On 3.5.2021 22:14 PM, Ed Lee wrote: > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote: > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote: > > >>>>> On 3.5.21 17.35, Ed Lee wrote: > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file?> > Please show the exact command line you're using for the as, so we can > > correct it. If you're using GCC to assemble a .s or .S file, the > > normal switches apply. > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ldLooks OK> user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld > arm-none-eabi-as: unrecognized option '-T' > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ldGiven correct main.o shoud be OK.> > There is a good reason to use the assembler only to create the .o file > > and make the linking in a separate step (using gcc again). > > > > Please remove the .org directives from your assembler code. The linker > > script is the proper way to locate various program sections. If you > > But gcc-as generates the wrong addresses with memory access.If you write correct asm your addresses will be correct. Look at following: ----------------<cut here>-------------------- .syntax unified .cpu cortex-m4 .text .Lstack: .word 0x20020000 .Lstart: .word start .text .org 512 .global start .thumb .thumb_func .type start, %function start: ldr r2, .L4 .L2: ldr r3, [r2] adds r3, r3, #1 str r3, [r2] b .L2 .align 2 .L4: .word c .comm c,4,4 ----------------<cut here>-------------------- Store to anull.s and do: arm-none-eabi-as -c anull.s -o anull.o arm-none-eabi-ld anull.o -T f411.ld -o anull.elf AFAICS it generates .elf file as you want. There is little weirdness with interrupt vectors: Tauno Voipio wanted vectors in separate section but I normally put them in .text, so using his linker script with my asm gives empty .romvec. Above I put just two vectors (should be enough to run) but in something serious there would be a subsection (written in C). -- Waldek Hebisch
gcc .data and .bss address space
Started by ●May 3, 2021
Reply by ●May 4, 20212021-05-04
Reply by ●May 4, 20212021-05-04
On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:> Ed Lee <edward....@gmail.com> wrote: > > On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote: > > > On 4.5.21 16.32, Ed Lee wrote: > > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote: > > > >> On 3.5.2021 22:14 PM, Ed Lee wrote: > > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote: > > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote: > > > >>>>> On 3.5.21 17.35, Ed Lee wrote: > > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file? > > > Please show the exact command line you're using for the as, so we can > > > correct it. If you're using GCC to assemble a .s or .S file, the > > > normal switches apply. > > > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld > Looks OK > > user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld > > arm-none-eabi-as: unrecognized option '-T' > > > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld > Given correct main.o shoud be OK. > > > There is a good reason to use the assembler only to create the .o file > > > and make the linking in a separate step (using gcc again). > > > > > > Please remove the .org directives from your assembler code. The linker > > > script is the proper way to locate various program sections. If you > > > > But gcc-as generates the wrong addresses with memory access. > If you write correct asm your addresses will be correct. > > Look at following: > ----------------<cut here>-------------------- > > .syntax unified > .cpu cortex-m4 > > .text > .Lstack: > .word 0x20020000 > .Lstart: > .word start > > .text > .org 512 > .global start > .thumb > .thumb_func > .type start, %function > start: > ldr r2, .L4r2 = 550 (aprox)> .L2: > ldr r3, [r2]r3 = c> adds r3, r3, #1r3 = d> str r3, [r2]store d to memory location 550 Segmentation violation. Can't write to ROM.> b .L2 > .align 2 > .L4: > .word c > > .comm c,4,4 > > ----------------<cut here>-------------------- > > Store to anull.s and do: > > arm-none-eabi-as -c anull.s -o anull.o > arm-none-eabi-ld anull.o -T f411.ld -o anull.elf > > AFAICS it generates .elf file as you want. There is little > weirdness with interrupt vectors: Tauno Voipio wanted vectors > in separate section but I normally put them in .text, > so using his linker script with my asm gives empty .romvec. > Above I put just two vectors (should be enough to run) but > in something serious there would be a subsection (written > in C). > > -- > Waldek Hebisch
Reply by ●May 4, 20212021-05-04
On 5/4/2021 12:22 PM, antispam@math.uni.wroc.pl wrote:> AFAICS it generates .elf file as you want. There is little > weirdness with interrupt vectors: Tauno Voipio wanted vectors > in separate section but I normally put them in .text, > so using his linker script with my asm gives empty .romvec. > Above I put just two vectors (should be enough to run) but > in something serious there would be a subsection (written > in C).In general (since forever) you can't go wrong with MORE sections. This makes the layout of the code visible to the link/load phase. I put the *ROM* copy of vectors in one section and the *RAM* copy in another (as the code will switch to the RAM copy once the ROM image has been verified and RAM initialized, program loaded, etc.). Likewise, the boot loader, BIST, etc. This lets you juggle where things should "fit" in the final image instead of having to examine the code, itself, to determine the structure. The tools are already there; let them do the work. [It also makes it easier to reuse "sections" from one project to the next]
Reply by ●May 4, 20212021-05-04
Ed Lee <edward.ming.lee@gmail.com> wrote:> On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote: > > Ed Lee <edward....@gmail.com> wrote: > > > On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote: > > > > On 4.5.21 16.32, Ed Lee wrote: > > > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote: > > > > >> On 3.5.2021 22:14 PM, Ed Lee wrote: > > > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote: > > > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote: > > > > >>>>> On 3.5.21 17.35, Ed Lee wrote: > > > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file? > > > > Please show the exact command line you're using for the as, so we can > > > > correct it. If you're using GCC to assemble a .s or .S file, the > > > > normal switches apply. > > > > > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld > > Looks OK > > > user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld > > > arm-none-eabi-as: unrecognized option '-T' > > > > > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld > > Given correct main.o shoud be OK. > > > > There is a good reason to use the assembler only to create the .o file > > > > and make the linking in a separate step (using gcc again). > > > > > > > > Please remove the .org directives from your assembler code. The linker > > > > script is the proper way to locate various program sections. If you > > > > > > But gcc-as generates the wrong addresses with memory access. > > If you write correct asm your addresses will be correct. > > > > Look at following: > > ----------------<cut here>-------------------- > > > > .syntax unified > > .cpu cortex-m4 > > > > .text > > .Lstack: > > .word 0x20020000 > > .Lstart: > > .word start > > > > .text > > .org 512 > > .global start > > .thumb > > .thumb_func > > .type start, %function > > start: > > ldr r2, .L4 > > r2 = 550 (aprox)Wrong, this is PC relative load that load value stored at .L4, that is 0x20000000 (address of c).> > .L2: > > ldr r3, [r2] > > r3 = c > > > adds r3, r3, #1 > > r3 = d > > > str r3, [r2] > > store d to memory location 550 > > Segmentation violation. Can't write to ROM.No, this is store to RAM (to c).> > b .L2 > > .align 2 > > .L4: > > .word c > > > > .comm c,4,4 > > > > ----------------<cut here>-------------------- > > > > Store to anull.s and do: > > > > arm-none-eabi-as -c anull.s -o anull.o > > arm-none-eabi-ld anull.o -T f411.ld -o anull.elf > > > > AFAICS it generates .elf file as you want. There is little > > weirdness with interrupt vectors: Tauno Voipio wanted vectors > > in separate section but I normally put them in .text, > > so using his linker script with my asm gives empty .romvec. > > Above I put just two vectors (should be enough to run) but > > in something serious there would be a subsection (written > > in C). > > > > -- > > Waldek Hebisch-- Waldek Hebisch
Reply by ●May 4, 20212021-05-04
On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, anti...@math.uni.wroc.pl wrote:> Ed Lee <edward....@gmail.com> wrote: > > On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote: > > > Ed Lee <edward....@gmail.com> wrote: > > > > On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote: > > > > > On 4.5.21 16.32, Ed Lee wrote: > > > > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote: > > > > > >> On 3.5.2021 22:14 PM, Ed Lee wrote: > > > > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote: > > > > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote: > > > > > >>>>> On 3.5.21 17.35, Ed Lee wrote: > > > > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file? > > > > > Please show the exact command line you're using for the as, so we can > > > > > correct it. If you're using GCC to assemble a .s or .S file, the > > > > > normal switches apply. > > > > > > > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld > > > Looks OK > > > > user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld > > > > arm-none-eabi-as: unrecognized option '-T' > > > > > > > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld > > > Given correct main.o shoud be OK. > > > > > There is a good reason to use the assembler only to create the .o file > > > > > and make the linking in a separate step (using gcc again). > > > > > > > > > > Please remove the .org directives from your assembler code. The linker > > > > > script is the proper way to locate various program sections. If you > > > > > > > > But gcc-as generates the wrong addresses with memory access. > > > If you write correct asm your addresses will be correct. > > > > > > Look at following: > > > ----------------<cut here>-------------------- > > > > > > .syntax unified > > > .cpu cortex-m4 > > > > > > .text > > > .Lstack: > > > .word 0x20020000 > > > .Lstart: > > > .word start > > > > > > .text > > > .org 512 > > > .global start > > > .thumb > > > .thumb_func > > > .type start, %function > > > start: > > > ldr r2, .L4 > > > > r2 = 550 (aprox) > Wrong, this is PC relative load that load value stored at .L4, > that is 0x20000000 (address of c).PC is approx 520. The assembler does not know about 0x20000000.
Reply by ●May 4, 20212021-05-04
Don Y <blockedofcourse@foo.invalid> wrote:> On 5/4/2021 12:22 PM, antispam@math.uni.wroc.pl wrote: > > AFAICS it generates .elf file as you want. There is little > > weirdness with interrupt vectors: Tauno Voipio wanted vectors > > in separate section but I normally put them in .text, > > so using his linker script with my asm gives empty .romvec. > > Above I put just two vectors (should be enough to run) but > > in something serious there would be a subsection (written > > in C). > > In general (since forever) you can't go wrong with MORE sections. > This makes the layout of the code visible to the link/load phase. > > I put the *ROM* copy of vectors in one section and the *RAM* > copy in another (as the code will switch to the RAM copy once > the ROM image has been verified and RAM initialized, program > loaded, etc.). > > Likewise, the boot loader, BIST, etc.You probably imagine something more complicated than STM32F411.> This lets you juggle where things should "fit" in the final image > instead of having to examine the code, itself, to determine the > structure. The tools are already there; let them do the work. > > [It also makes it easier to reuse "sections" from one project > to the next]The example is a toy which IMO fulfils its purpose. As I wrote I have vectors as subsection, in linker script I can put it where I want it, simply to the moment it was most convenient to put it in .text. With my setup I can link .text so that it goes to RAM, which is convenient for debugging small programs or to ROM (usual setup). Script provided by Tauno Voipio creates overlapped sections in final executable, I do not know why. I can imagine use of overlapped sections in RAM, but what they buy in ROM? Personaly, I am trying to avoid unnecessary complexity. Currently linker scripts give me enough possibilities to rearrange code, so I felt no need to additionally juggle sections in executable (that would be different if an OS was present, but I am talking here about programs running on bare hardware). -- Waldek Hebisch
Reply by ●May 4, 20212021-05-04
On 5/4/2021 4:14 PM, antispam@math.uni.wroc.pl wrote:> Don Y <blockedofcourse@foo.invalid> wrote: >> On 5/4/2021 12:22 PM, antispam@math.uni.wroc.pl wrote: >>> AFAICS it generates .elf file as you want. There is little >>> weirdness with interrupt vectors: Tauno Voipio wanted vectors >>> in separate section but I normally put them in .text, >>> so using his linker script with my asm gives empty .romvec. >>> Above I put just two vectors (should be enough to run) but >>> in something serious there would be a subsection (written >>> in C). >> >> In general (since forever) you can't go wrong with MORE sections. >> This makes the layout of the code visible to the link/load phase. >> >> I put the *ROM* copy of vectors in one section and the *RAM* >> copy in another (as the code will switch to the RAM copy once >> the ROM image has been verified and RAM initialized, program >> loaded, etc.). >> >> Likewise, the boot loader, BIST, etc. > > You probably imagine something more complicated than STM32F411.I try to solve similar problems in very similar ways. So, I don't have to explain why I did "something different" in one case (but not another).>> This lets you juggle where things should "fit" in the final image >> instead of having to examine the code, itself, to determine the >> structure. The tools are already there; let them do the work. >> >> [It also makes it easier to reuse "sections" from one project >> to the next] > > The example is a toy which IMO fulfils its purpose. As I wrote > I have vectors as subsection, in linker script I can put it > where I want it, simply to the moment it was most convenient > to put it in .text. With my setup I can link .text so that > it goes to RAM, which is convenient for debugging small programs > or to ROM (usual setup). Script provided by Tauno Voipio > creates overlapped sections in final executable, I do not > know why. I can imagine use of overlapped sections in RAM, > but what they buy in ROM?I've not examined the post so can't comment on specifics. As to overlaying "ROM", I've done so (ages ago) in the era of bank-switched hardware -- switching ROM *out* of an address space after POST so those reserved locations (common in smaller MPUs) could be more effectively used (out of RAM). Likewise, swapping banks of RAM into portions of the logical address space (to support independent stacks and heaps for many threads). You can also overlay read and write accesses to portions of an address space (e.g., read an address yields one datum while writing drives another -- most common in mapped I/O) <shrug> Dunno. But, in each case, doing it in the code makes the code more brittle; if the address map changes, then the *code* has to change. And, the change has to be ferreted out (instead of exposed in a simple script).> Personaly, I am trying to avoid unnecessary complexity. > Currently linker scripts give me enough possibilities > to rearrange code, so I felt no need to additionally > juggle sections in executable (that would be different > if an OS was present, but I am talking here about > programs running on bare hardware).Every project I've built runs on bare iron. Even my current project has to install the POST/BIST/loader/etc. on bare iron *before* it can load (over the wire) the actual OS and, then, the application. On reset, I have to ensure the initial PC, etc. is available (from "ROM"). A small/tight checksum routine to verify the next stage of boot is intact. Then, code to verify the hardware can be used *by* that next stage of the boot (i.e., do I have any functional RAM?) Eventually, invoking specific test routines for *this* hardware (different set of I/Os than other devices running the same boot code) by probing a portion of the address space into which those ROM-based routines would exist. All that before beginning to set up the environment and network stack to download the OS image. Plus, a "safe" copy of the boot loader so I can reflash without fear of making a brick. Having a "rich" structure/methodology to call upon for juggling these various "boxes" makes it easier to add as new requirements come along. And, exposes these details at a higher level (so the Next Guy isn't scratching his head wondering why "this is here" and "that is there"). [I.e., it's easier to document a script than it is to embed lots of notes in a variety of different files and HOPING the Next Guy can find all of them!]
Reply by ●May 4, 20212021-05-04
Ed Lee <edward.ming.lee@gmail.com> wrote:> On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, anti...@math.uni.wroc.pl wrote: > > Ed Lee <edward....@gmail.com> wrote: > > > On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote: > > > > Ed Lee <edward....@gmail.com> wrote: > > > > > On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote: > > > > > > On 4.5.21 16.32, Ed Lee wrote: > > > > > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote: > > > > > > >> On 3.5.2021 22:14 PM, Ed Lee wrote: > > > > > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote: > > > > > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote: > > > > > > >>>>> On 3.5.21 17.35, Ed Lee wrote: > > > > > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file? > > > > > > Please show the exact command line you're using for the as, so we can > > > > > > correct it. If you're using GCC to assemble a .s or .S file, the > > > > > > normal switches apply. > > > > > > > > > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld > > > > Looks OK > > > > > user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld > > > > > arm-none-eabi-as: unrecognized option '-T' > > > > > > > > > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld > > > > Given correct main.o shoud be OK. > > > > > > There is a good reason to use the assembler only to create the .o file > > > > > > and make the linking in a separate step (using gcc again). > > > > > > > > > > > > Please remove the .org directives from your assembler code. The linker > > > > > > script is the proper way to locate various program sections. If you > > > > > > > > > > But gcc-as generates the wrong addresses with memory access. > > > > If you write correct asm your addresses will be correct. > > > > > > > > Look at following: > > > > ----------------<cut here>-------------------- > > > > > > > > .syntax unified > > > > .cpu cortex-m4 > > > > > > > > .text > > > > .Lstack: > > > > .word 0x20020000 > > > > .Lstart: > > > > .word start > > > > > > > > .text > > > > .org 512 > > > > .global start > > > > .thumb > > > > .thumb_func > > > > .type start, %function > > > > start: > > > > ldr r2, .L4 > > > > > > r2 = 550 (aprox) > > Wrong, this is PC relative load that load value stored at .L4, > > that is 0x20000000 (address of c). > > PC is approx 520. The assembler does not know about 0x20000000.Have you tried provided commands? There is also objdump, run arm-none-eabi-objdump -D anull.elf to see what is in .elf file. And compare with arm-none-eabi-objdump -D anull.o And yes, assember produces relocatable code and does not know addresses. It is linker job to put addresses into ELF executable. -- Waldek Hebisch
Reply by ●May 4, 20212021-05-04
On Tuesday, May 4, 2021 at 5:21:46 PM UTC-7, anti...@math.uni.wroc.pl wrote:> Ed Lee <edward....@gmail.com> wrote: > > On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, anti...@math.uni.wroc.pl wrote: > > > Ed Lee <edward....@gmail.com> wrote: > > > > On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote: > > > > > Ed Lee <edward....@gmail.com> wrote: > > > > > > On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote: > > > > > > > On 4.5.21 16.32, Ed Lee wrote: > > > > > > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote: > > > > > > > >> On 3.5.2021 22:14 PM, Ed Lee wrote: > > > > > > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote: > > > > > > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote: > > > > > > > >>>>> On 3.5.21 17.35, Ed Lee wrote: > > > > > > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file? > > > > > > > Please show the exact command line you're using for the as, so we can > > > > > > > correct it. If you're using GCC to assemble a .s or .S file, the > > > > > > > normal switches apply. > > > > > > > > > > > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld > > > > > Looks OK > > > > > > user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld > > > > > > arm-none-eabi-as: unrecognized option '-T' > > > > > > > > > > > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld > > > > > Given correct main.o shoud be OK. > > > > > > > There is a good reason to use the assembler only to create the .o file > > > > > > > and make the linking in a separate step (using gcc again). > > > > > > > > > > > > > > Please remove the .org directives from your assembler code. The linker > > > > > > > script is the proper way to locate various program sections. If you > > > > > > > > > > > > But gcc-as generates the wrong addresses with memory access. > > > > > If you write correct asm your addresses will be correct. > > > > > > > > > > Look at following: > > > > > ----------------<cut here>-------------------- > > > > > > > > > > .syntax unified > > > > > .cpu cortex-m4 > > > > > > > > > > .text > > > > > .Lstack: > > > > > .word 0x20020000 > > > > > .Lstart: > > > > > .word start > > > > > > > > > > .text > > > > > .org 512 > > > > > .global start > > > > > .thumb > > > > > .thumb_func > > > > > .type start, %function > > > > > start: > > > > > ldr r2, .L4 > > > > > > > > r2 = 550 (aprox) > > > Wrong, this is PC relative load that load value stored at .L4, > > > that is 0x20000000 (address of c). > > > > PC is approx 520. The assembler does not know about 0x20000000. > Have you tried provided commands? There is also objdump, run > > arm-none-eabi-objdump -D anull.elf > > to see what is in .elf file. And compare with > > arm-none-eabi-objdump -D anull.o > > And yes, assember produces relocatable code and does not know > addresses. It is linker job to put addresses into ELF executable.Yes, i have been looking at object files, elf and bin files, with objdump, readelf, od and hexdump. The linker relocates the data to the ram address, but does not change the content, which is still pointing to the rom address. I am just trying to convince myself how is that possible to work without the assembler knowing the actual physical address of ram.
Reply by ●May 4, 20212021-05-04
On 5/4/2021 6:06 PM, Ed Lee wrote:> I am just trying to convince myself how is that possible to work without the > assembler knowing the actual physical address of ram."RAM" is just a set of one (or more) labels that you have located in a data segment. How does the assembler know how to access a subroutine that you've defined IN ANOTHER MODULE? The linkage editor knows how to resolve cross-module labels. So, you can reference a location in "ROM" or "RAM" without the actual instruction knowing the difference. The loader maps addresses of sections to physical addresses. So, you end up with a binary that has been *bound* to a specific set of constraints -- inter-module and inter-section.
