Microchip Technology SW006021-2 Manual De Usuario
C Language Features
2012 Microchip Technology Inc.
DS52053B-page 169
5.5.2.2
AUTO VARIABLE ALLOCATION AND ACCESS
This section discusses allocation of auto variables (those with automatic storage dura-
tion). This also include function parameter variables, which behave like auto variables
in terms of their storage duration and scope. Temporary variables defined by the com-
piler also fall into this group. They are identical to autos except they are defined by the
compiler, not the programmer, and as a result, have no C name.
tion). This also include function parameter variables, which behave like auto variables
in terms of their storage duration and scope. Temporary variables defined by the com-
piler also fall into this group. They are identical to autos except they are defined by the
compiler, not the programmer, and as a result, have no C name.
The auto (short for automatic) variables are the default type of local variable. Unless
explicitly declared to be static, a local variable will be made auto. The auto key-
word may be used if desired.
explicitly declared to be static, a local variable will be made auto. The auto key-
word may be used if desired.
The auto variables, as their name suggests, automatically come into existence when
a function is executed, then disappear once the function returns. Since they are not in
existence for the entire duration of the program, there is the possibility to reclaim mem-
ory they use when the variables are not in existence and allocate it to other variables
in the program.
a function is executed, then disappear once the function returns. Since they are not in
existence for the entire duration of the program, there is the possibility to reclaim mem-
ory they use when the variables are not in existence and allocate it to other variables
in the program.
Typically such variables are stored on some sort of a data stack, which can easily allo-
cate then deallocate memory as required by each function. All devices targeted by the
compiler do not have a data stack that can be operated in this fashion. The devices can
only use their hardware stack for function return addresses and have no instructions
which allow data to be placed onto this stack. As a result, an alternative stack construct
is implemented by the compiler. The stack mechanism employed is known as a com-
piled stack and is fully described in Section 5.5.2.2.1 “Compiled Stack Operation”.
cate then deallocate memory as required by each function. All devices targeted by the
compiler do not have a data stack that can be operated in this fashion. The devices can
only use their hardware stack for function return addresses and have no instructions
which allow data to be placed onto this stack. As a result, an alternative stack construct
is implemented by the compiler. The stack mechanism employed is known as a com-
piled stack and is fully described in Section 5.5.2.2.1 “Compiled Stack Operation”.
Once auto variables have been allocated a relative position in the compiled stack, the
stack itself is then allocated memory in the data space. This is done is a similar fashion
to the way non-auto variables are assigned memory: a psect is used to hold the stack
and this psect is placed into the available data memory by the linker. The psect base
name used to hold the compiled stack is called cstack, and like with non-auto vari-
able psects, the base name is always used in conjunction with a linker class name to
indicate the RAM bank in which the psect will be positioned. See
Section 5.15.2 “Compiler-Generated Psects” for the limitations associated with
where this psect can be linked.
stack itself is then allocated memory in the data space. This is done is a similar fashion
to the way non-auto variables are assigned memory: a psect is used to hold the stack
and this psect is placed into the available data memory by the linker. The psect base
name used to hold the compiled stack is called cstack, and like with non-auto vari-
able psects, the base name is always used in conjunction with a linker class name to
indicate the RAM bank in which the psect will be positioned. See
Section 5.15.2 “Compiler-Generated Psects” for the limitations associated with
where this psect can be linked.
The auto variables defined in a function will not necessarily be allocated memory in
the order declared, in contrast to parameters which are always allocated memory
based on their lexical order. In fact, auto variables for one function may be allocated
in many RAM banks.
the order declared, in contrast to parameters which are always allocated memory
based on their lexical order. In fact, auto variables for one function may be allocated
in many RAM banks.
The standard qualifiers: const and volatile may both be used with auto variables
and these do not affect how they are positioned in memory. This implies that a local
const
and these do not affect how they are positioned in memory. This implies that a local
const
-qualified object is still an auto object and, as such, will be allocated memory in
the compiled stack in the data space memory, not in the program memory like with
non-auto const objects.
non-auto const objects.
The compiler will try to locate the stack in one data bank, but if this fills (i.e., if the com-
piler detects that the stack psect has become too large), it can build up the stack into
several components (each with their own psect) and link each in a different bank.
piler detects that the stack psect has become too large), it can build up the stack into
several components (each with their own psect) and link each in a different bank.
Each auto object is referenced in assembly code using a special symbol defined by
the code generator. If accessing auto variables defined in C source code, you must use
these symbols, which are discussed in Section 5.12.3 “Interaction Between
Assembly and C Code”.
the code generator. If accessing auto variables defined in C source code, you must use
these symbols, which are discussed in Section 5.12.3 “Interaction Between
Assembly and C Code”.
5.5.2.2.1
Compiled Stack Operation
A compiled stack consists of fixed memory areas that are usable by each function’s
stack-based variables. When a compiled stack is used, functions are not re-entrant
since stack-based variables in each function will use the same fixed area of memory
every time the function is invoked.
stack-based variables. When a compiled stack is used, functions are not re-entrant
since stack-based variables in each function will use the same fixed area of memory
every time the function is invoked.