Hi!
Indeed, if you use segments, the assembler does not know the absolute address
of any reference and has to leave this stop to the linker. But you don't need
to use segments. segments are just to make a linker step
possible (and necessary).
If you use the .org directive for defining you variables and to place your
code, all references have a dedicated absolute address at assembly time and the
assembler should not generate any relocation entry. So no
linker is needed at all. It IS possible to generate a complete program
including vector table and such this way. But it is not as comfortable as it is
with linker.
Of course the labels are exported anyways to tell them to the linker if the
code shall be linked together with other object files.
for example, the source code
.org 0x0200
var1: .dw 0
var2: .db 0
var3: .db 0
.org 0xe000
main: mov.b var3,#1
mov var1, var2
end: jmp end
.org 0xfffe
reset: .dw main
should produce a fully functionable program, resulting in #0x100 at 0x0200 (ram
area, I think)
The code above is just a rough example. The mnemonics are likely not correct
(I'm not an assembler programmer and I've just written it without any look into
a reference book), but it should be clear enough to get the
point.
The only thing is that the resulting binary file would be almost 64k sized
(0x0200 to 0xFFFF)and must be split somehow to cut-out the really flashable
portions. And to remove the additional info the assembler puts
into the output file for the linker and/or the debugger.
JMGross
----- Ursprüngliche Nachricht -----
Von: Przemek Klosowski
An: [email protected]
Gesendet am: 14 Aug 2009 03:58:04
Betreff: Re: [Mspgcc-users] Unexpected output from msp430-gcc assembler (simple
problem?)
>
> As long as you do not have unknown symbols (e.g. if you only have one
> single source file, a contiguous block of code and no libraries), you don't
> really need the linker. There shouldn't be any unresolved external
> symbols.
There has to be a link step. I checked that both forward and backward
references to labels the OP used are recorded in the ELF object file as
relocations. This makes sense, because the linker must relocate the segments
according to the target system memory map, so that the value of the labels
changes and the addresses must be adjusted----unless the assembler was able
to provide the final relocation itself which no one so far seemed to know
how to do.
Bottom line: go along with the way toolchain wants to work. Number one
recommendation is to use inline assembly in C and let the gcc driver execute
the required toolchain sequence. Barring that, use explicit assemble and
link steps.
Thanks to JMGross for a good overview of the linking step, btw!
