5.15.1 Compiler-Generated Psects

The code generator places code and data into psects, or sections, with standard names, which are subsequently 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 6.1.9.39 Psect Directive).

The names of psects are case sensitive. Some psects use special naming conventions, for example, the bss psect, which holds uninitialized objects. There may be uninitialized objects 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 objects 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.

The general form of data psect names is:

[bit]psectBaseNameCLASS[div]

where psectBaseName is the base name of the psect (listed in 5.15.1.2 Data Space Psects). The CLASS is a name derived from the linker class (see 5.15.2.2 Data Memory Classes) in which the psect will be linked, e.g., BANK0. The prefix bit is used if the psect holds __bit variables. So there can be psects like: bssBANK0, bssBANK1 and bitbssBANK0 defined by the compiler to hold the uninitialized variables.

Note that __eeprom-qualified variables can define psects called bssEEDATA or dataEEDATA, for example, in the same way. Any psect using the class suffix EEDATA is placed in the HEX file and is burnt into the EEPROM space when you program the device.

If a data psect needs to be split around a reserved area, it will use the letters l and h (as div in the above form) 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 6.3.1 General Format).