User manual

C Language Features
 2012 Microchip Technology Inc. DS52053B-page 231
The hold of a ship or aircraft might be a very large space, but freight is always packed
into shipping containers and it is the size of the shipping container that dictates the
maximum size of a object that can be transported. In the same way, the total amount
of memory on a target device is irrelevant if sections must first be allocated to a class.
Classes may seem restrictive, but without them, code will typically be less efficient or
may simply fail to work altogether. The computed goto is a good example. If the table
of instructions in a computed goto crosses a 100h boundary, it will fail due to the limited
jump range of the instruction set.
This space error may also occur if there are many free spaces remaining in containers,
but none are large enough to hold the section. This can be confusing since the total
amount of free space may be larger than the section to be placed. In the same way that
boxes cannot be removed from a bundle or unpacked, if a section does not fit into any
remaining space, it cannot be split by the linker and an error will result. The error
message indicates that largest free space that is still available.
In the same way that the label on a box may indicate special packing instructions, e.g.,
“fragile – pack at the top of the container”, or “this way up”, etc, a section can also indi-
cate special memory allocation instructions. One of the most common requirements is
that a section must start on an address boundary, see the reloc PSECT flag in
Section 6.4.9.3.11 “Reloc”. If a section has to fit into a class, but also has to be
aligned on an address, this makes it much more difficult to locate and increases the
chance that this error is produced. This is also the case if other sections or objects have
been placed in the middle of a container, as we saw in Section 5.15.1.4.1 “Allocation
at Specific Locations”.
5.15.1.6.2 Not Being Shipped in the Right Container
Clearly, boxes will not be delivered correctly if they are placed in the wrong container.
So too, code may not run if it is placed in the wrong class or address. The compiler will
always ensure that code and data is allocated correctly, but it is possible to manually
change linker options.
The code generator assumes that sections will be located in certain memory areas and
the code it generates may rely on this being the case. Typically, sections placed in RAM
must remain in the bank in which they were originally destined. Sections containing
executable code maybe more forgiving, but some have very specific requirements.
Remember, the linker will allow any allocation you indicate; it has no way of checking
if what you tell it is correct. Always take care if you override linker options and reposition
a section. Section 5.15.2 “Compiler-Generated Psects” lists the common sections
used by the compiler. it also indicates restrictions on how these sections may be linked.
5.15.1.6.3 Doing Things by Hand
So far we have discussed assembly code produced by the code generator and how it
is linked into memory; now, we consider hand-written assembly.
Imagine that in the warehouse an order is not processed by the robot, but by a human
worker. The components ordered are assembled by hand, packed in a box by hand and
then placed on the conveyor belt along with those boxes packed by the robot. This is
quite similar to when there is hand-written assembly code in a project: the linker is
passed a number of sections, some created by the code generator and some by a
human.
Mistakes can be made by the warehouse worker or the assembly programmer. In the
warehouse, the worker might not use a box and place the components loose on the
conveyor belt, or a box might be used but it is not labelled, or it might be labelled incor-
rectly. In the compiler’s domain, assembly code may be written without a section, or it
is in a section but with the wrong (or no) class, or the section may have incorrect
allocation instructions.