Default Allocation Algorithm and Special Section Types

Using the MEMORY and SECTIONS directives provides you with a great deal of flexibility in specifying how sections will be built and combined. However, anything that you choose not to specify must still be handled by the linker.

The linker has default algorithms that it uses to build and allocate sections, within the specifications you supply. Section 9.8.1 and Section 9.8.2 describe default allocation algorithms.

The linker also has the ability to create sections that are handled differently than the normal allocation algorithm specifies; Section 9.8.3 describes these sections.

9.S.1 Default Allocation Algorithm

9-24

If you do not use any MEMORY or SECTIONS directives, the linker acts as though the following definitions were specified:

MEMORY

{

RFILE origin 0OO2h length OFEh EEPROM origin lFOOh length lOOh ROM origin 7000h length lOOOh

}

SECTIONS

{

.reg > ^RFILE .bss > ^RFILE .text > ^EEPROM .data > ^ROM

All .reg (relocatable register) input sections are concatenated to form one .reg output section, and all .bss input sections are concatenated to form one .bss output section. The .reg section is then linked into the register file, starting at location 02h (register R2), followed by the .bss section. All .data input sections are combined to form a .data output section, which is linked into EEPROM starting at location 1 FOOh. All .text input sections are concatenated to form a .text output section, which is linked into program memory starting at location 7000h.

Unless you specify otherwise with a MEMORY directive, the linker assumes the configuration specified above. That is, the only memory that the linker will use to build you program is:

• 254 bytes starting at location 02h

• 256 bytes starting at location 1 FOOh

• 4K bytes starting at location 7000h

If there are additional input sections in the input files (specifically, named sections), the linker will link them in after the default sections have been linked. Input sections that have the same name are combined into a single output section with this name. The linker allocates these additional output sections into memory where ever there is room. Usually it is desirable to use explicitSECTIONS directives to tell the linker where to place named sections.

Linker Description - Default Allocation Algorithm

Note:

If a SECTIONS directive is specified, the linker performs no part of the default allocation. Allocation is performed according to the rules specified by the SECTIONS directive and the general algorithm described below.

9.8.2 General Rules for Output Sections

An output section can be formed in one of two ways:

1} As the result of a SECTIONS directive definition.

2} By combining input sections with the same names into output sections that are not defined in a SECTIONS directive.

If an output section is formed as a result of a SECTIONS directive (rule 1), its specification in the directive completely determines its contents. The contents of an output section in the SECTIONS directive is given by the information within the inner braces after the section name. (See Section 9.6 for examples of how to specify the contents of output sections.)

An output section can also be formed when input sections are encountered that are not specified by any SECTIONS directive (rule 2). In this case, the linker combines all such input sections with the same name into an output section with this name. For example, suppose the files f 1. obj and f 2. obj both contain named sections called Vectors and that the SECTIONS direc-tive does not define an output section called Vectors. The linker will com-bine the two Vectors sections from the input files into a single output section named Vectors, allocate it into memory, and include it in the output file.

After the linker determines the composition of all the output sections, it must allocate them into configured memory. The MEMORY directive specifies which portions of memory are configured, or if there is no MEMORY directive, the default configuration is used.

The linker uses an allocation algorithm that attempts to minimize memory fragmentation, which allows memory to be used more efficiently and increases the probability that your program will fit into memory. This is the algorithm:

1} Output sections for which you have listed a specific binding address are placed in memory at that address.

2} Output sections that are included in a specific named memory range or that have memory attribute restrictions are allocated. Each output sec-tion is placed into the first available space within the named area, con-sidering alignment where necessary.

3} Any remaining sections are allocated in the order in which they were defined. Sections not defined in a SECTIONS directive are allocated in the order in which they were encountered. Each output section is placed in to the first available memory space, considering alignment where ne-cessary.

9-25

linker Description - Default Allocation Algorithm

Note:

If you do not use the PAGE option to explicitly specify a memory space for an output section, the linker will allocate the section into page O. This will occur even if there is no room on page 0 but there is space on other pages. To use a page other than page 0, you must specify the page with the SECTIONS directive.

9.8.3 DSECT, COPY, and NOlOAD Sections

9-26

There are three special types that you can assign to output sections. These types affect the way that the program is treated when it is linked and loaded.

These types are DSECT, COPY, and NOLOAD. A type may be assigned to a section by placing the type (enclosed in parenthesis) after the section defi-nition. For example,

SECTIONS {

secl 2000h (DSECT) sec2 4000h (COPY) sec3 6000h (NOLOAD)

{flo obj}

{flo obj}

{flo obj}

• The DSECT type creates a "dummy section" that has the following qualities:

It is not included in the output section memory allocation. It takes up no memory and is not included in the memory map listing.

It can overlay other output sections, other DSECTs, and unconfig-ured memory.

Global symbols defined in a dummy section are relocated normally.

They appear in the output module's symbol table with the same value they would have if the DSECT had actually been loaded.

These symbols can be referenced by other input sections.

Undefined external symbols found in a DSECT cause specified ar-chive libraries to be searched.

The section's contents, relocation information, and line number information are not placed in the output module.

In the preceding example, none of the sections from fl.obj are allo-cated, but all the symbols are relocated as though the sections were linked at address 2000h. The other sections can refer to any of the glo-bal symbols in secl.

• A COpy section is identical to a DSECT section, except that its contents and associated information are written to the output module.

• A NOLOAD section differs from a normal output section in one respect:

it is not written to the output module. It is allocated space, appears in the memory map listing, etc. .

Linker Description - Assigning Symbols at Link Time