Microchip Technology XC8 Standard Compiler (Workstation) SW006021-1 SW006021-1 User Manual

®

DS52053B-page 232

 2012 Microchip Technology Inc.

If assembly code is not in a section, the compiler will actually place it into a default sec-
tion. But since there are no specific instructions as to what to do with this section, it 
could be linked anywhere. Such sections are like boxes labelled “ship to anywhere you 
want”. As a rule of thumb, put all assembly code inside a section, but some directives 
(e.g., GLOBAL or EQU) do not generate code and can be placed anywhere.

The easiest way to write and locate hand-written assembly code is to associate the 
section you create with an existing linker class that represents a suitable memory area. 
This means the default linker options do not need to be altered.

The association is made using the class flag of the PSECT directive, see 
Section 6.4.9.3.3 “Class”. If a section is to be placed at an explicit address rather than 
having it placed anywhere in a class, the class flag should still be used. A list of linker 
classes and the memory they represent is given in Section 5.15.3 “Default Linker 
Classes”.

Even if you place your code into a section and use an appropriate class, other flags 
may be necessary to correctly link the code. The most important section flags are the 
delta

, see Section 6.4.9.3.4 “Delta”, reloc, see Section 6.4.9.3.11 “Reloc” and 

space

, see 6.4.9.3.13 “Space” flags. If these are incorrectly specified, the code not 

be positioned correctly and will almost certainly fail.

The code generator places code and data into psects (program sections) with standard 
names, which are subsequent positioned by the default linker options. The linker does 
not treat these compiler-generated psects any differently to a psect that has been 
defined by yourself. A psect can be created in assembly code by using the PSECT 
assembler directive (see Section 6.4.9.3 “PSECT”). The code generator uses this 
directive to direct assembly code it produces into the appropriate psect. For an intro-
ductory guide to psects, see Section 5.15.1 “Program Sections”.

Some psects, in particular the data memory psects, use special naming conventions.

For example, take the bss psect. The name bss is historical. It holds uninitialized vari-
ables. However, there may be some uninitialized variables that will need to be located 
in bank 0 data memory; others may need to be located in bank 1 memory. As these two 
groups of variables will need to be placed into different memory banks, they will need 
to be in separate psects so they can be independently controlled by the linker. In addi-
tion, the uninitialized variables that are bit variables need to be treated specially so 
they need their own psect. So there are a number of different psects that all use the 
same base name, but which have prefixes and suffixes to make them unique.

The general form of these psect names is:

[bit]psectBaseNameCLASS[div]

where psectBaseName is the base name of the psect, such as bss. The CLASS is a 
name derived from the linker class (see Section 7.2.1 “-Aclass =low-high,...”) in 
which the psect will be linked, e.g., BANK0. The prefix bit is used if the psect holds 
bit

 variables. So there may be psects like: bssBANK0, bssBANK1 and bitbssBANK0 

defined by the compiler to hold the uninitialized variables.

If locations in a bank are reserved or are taken up by absolute objects for example, a 
psect cannot be formed over the entire bank. Instead, a separate psect will be used to 
represent the free memory on either side of the used memory. The letters l (elle) and 
h

 are used as the div field in the psect name to indicate if it is the lower or higher 

division. Thus you might see bssBANK0l and bssBANK0h psects if a split took place.

If you are unsure which psect holds an object or code in your project, check the 
assembly list file (see Section 6.6.1 “General Format”

The contents of these psects are described below, listed by psect base name.