User manual

ST Assembler-Linker Linker
Doc ID 11392 Rev 4 41/89
For example:
grafix segment byte at: 100-027F 'RAM1'
cursor_buf ds.b 64 ; buffer for map under cursor
segment byte at: 8000-BFFF 'ROM'
show_page nop
segment 'RAM1'
field-buf ds.b {{256 mult 256}/8}
segment 'ROM'
dump_buf ld A,field_buffer
grafix segment 'RAM1'
cursor_temp ds.b 64
This complex sequence of segments shows now instances of the class RAM1 being used
with a segment name of grafix. Because the first instance of the class RAM1 had the
name grafix the two grafix RAM1 segments are placed in memory first followed by the
null-name RAM1 segment (which defines field_buf). Note this is not the order of the
segments in the code, segments with the same name are collated together (even from
separate .OBJ files), and the lumps of segments of the same name are put into memory in
the order that the names are found in the .OBJ files.
As explained on page 29, if x is your cod file suffix when introducing a class, all code for that
code is sent into a new cod-file named file_x.cod, where file is the name of the first
cod file, and x is the cod-file suffix (1-9).
5.4.3 Symbol files
At the end of a successful link, one or more .OBJ files will have been combined into a single
.COD file. A .MAP file will have been produced, containing textual information about the
segments, classes and external labels used by the .OBJ module(s). Finally a compact
.SYM file is generated, containing all PUBLIC symbols found in the link with their final
values.
The linker supports a special feature, you can link in .SYM files from other link sessions.
This means that with big programs, you cannot only partition your code at assembler level,
but divide the code up into 'lumps' which are linked and loaded separately, but have access
to each other's label as EXTERNs. You can 'link in' a symbol table simply by giving its name
with the suffix .SYM. Always give symbol tables at the start of the object file list.
OBJ file example: LYN prog1.sym+prog2,vectors,irq;
Once this is done, all the PUBLIC symbols from prog1.sym are now available as PUBLICs
to prog2.obj, vectors.obj and irq.obj.
Because changes in one link will not automatically update references to the changed link
code in other links, it is necessary when using this technique to 'fix' each link in an area of
memory, and have a 'jump table' at the top of each area. This means that all 'function'
addresses are permanently fixed as jump table offset, and changes to each link will result in
automatic redirection of the jump targets to the new start of each routine. Put another way,
each link must have entry fixed points to all its routine, otherwise re-linking one 'lump' of a
program could make references to its addresses in other modules out of date.