Microchip Technology SW006021-2 ユーザーズマニュアル
MPLAB
®
XC8 C Compiler User’s Guide
DS52053B-page 172
2012 Microchip Technology Inc.
The end result is a block of memory which forms the compiled stack. This block can
then be placed into the device’s memory by the linker.
then be placed into the device’s memory by the linker.
For devices with more than one bank of data memory, the compiled stack may be built
up into components, each located in a different memory bank. The compiler will try to
allocate the compiled stack in one bank, but if this fills, it will consider other banks. The
process of building these components of the stack is the same, but each function may
have more than one APB and these will be allocated to one of the stack components
based on the remaining memory in the component’s destination bank.
up into components, each located in a different memory bank. The compiler will try to
allocate the compiled stack in one bank, but if this fills, it will consider other banks. The
process of building these components of the stack is the same, but each function may
have more than one APB and these will be allocated to one of the stack components
based on the remaining memory in the component’s destination bank.
Human readable symbols are defined by the code generator which can be used to
access auto and parameter variables in the compiled stack from assembly code, if
required. See Section 5.12.3 “Interaction Between Assembly and C Code” for full
information between C domain and assembly domain symbols.
access auto and parameter variables in the compiled stack from assembly code, if
required. See Section 5.12.3 “Interaction Between Assembly and C Code” for full
information between C domain and assembly domain symbols.
5.5.2.3
Size Limits of Auto Variables
The compiled stack is built up as one contiguous block which can be placed into one
of the available data banks. However, if the stack becomes too large for this space, it
can be assembled into several blocks, with each block being positioned in a different
bank of memory. Thus the total size of the stack is roughly limited only by the available
memory on the device.
of the available data banks. However, if the stack becomes too large for this space, it
can be assembled into several blocks, with each block being positioned in a different
bank of memory. Thus the total size of the stack is roughly limited only by the available
memory on the device.
Unlike with non-auto variables, it is not efficient to access auto variables within the
compiled stack using the linear memory of Enhanced mid-range devices. Thus, for all
devices, including PIC18 and Enhanced mid-range PIC MCUs, each component of the
compiled stack must fit entirely within one bank of data memory on the target device
(however, you can have more than one component, each allocated to a different bank).
This limits the size of objects within the stack to the maximum free space of the bank
in which it is allocated. The more auto variables in the stack; the more restrictive the
space is to large objects. Recall that SFRs on mid-range devices are usually present
in each data bank, so the maximum amount of GPR available in each bank is typically
less than the bank size for these devices.
compiled stack using the linear memory of Enhanced mid-range devices. Thus, for all
devices, including PIC18 and Enhanced mid-range PIC MCUs, each component of the
compiled stack must fit entirely within one bank of data memory on the target device
(however, you can have more than one component, each allocated to a different bank).
This limits the size of objects within the stack to the maximum free space of the bank
in which it is allocated. The more auto variables in the stack; the more restrictive the
space is to large objects. Recall that SFRs on mid-range devices are usually present
in each data bank, so the maximum amount of GPR available in each bank is typically
less than the bank size for these devices.
If a program requires large objects that should not be accessible to the entire program,
consider leaving them as local objects, but using the static specifier. Such variables
are still local to a function, but are no longer auto and have fewer size limitations. They
are allocated memory as described in Section 5.5.2.1 “Non-Auto Variable
Allocation”.
consider leaving them as local objects, but using the static specifier. Such variables
are still local to a function, but are no longer auto and have fewer size limitations. They
are allocated memory as described in Section 5.5.2.1 “Non-Auto Variable
Allocation”.
5.5.2.4
CHANGING THE DEFAULT AUTO VARIABLE ALLOCATION
As auto variables are placed in a stack, there is no means to move individual vari-
ables. They cannot be made absolute, nor can they be moved using the #pragma
psect
ables. They cannot be made absolute, nor can they be moved using the #pragma
psect
directive.
The psects in which the auto variables reside can be shifted as a whole by changing
the default linker options. However, these psects can only be moved within the data
bank in which they were allocated by default. See Section 5.10 “Main, Runtime
Startup and Reset” for more information on changing the default linker options for
psects. The code generate makes assumptions as to the location of these psects and
if you move them to a location that breaks these assumptions, code may fail.
the default linker options. However, these psects can only be moved within the data
bank in which they were allocated by default. See Section 5.10 “Main, Runtime
Startup and Reset” for more information on changing the default linker options for
psects. The code generate makes assumptions as to the location of these psects and
if you move them to a location that breaks these assumptions, code may fail.