# Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

### Protego

# MPLAB XC16 C-Compiler

- 1
- 2
…
- 145
- 146
- 147
- 148
- 149
…
- 365
- 366

Memory Allocation and Access
 2012-2013 Microchip Technology Inc. DS50002071C-page 147
To declare an initialized array in data EEPROM without special alignment:
int _EEDATA(2) table1[] = {0, 1, 1, 2, 3, 5, 8, 13, 21};
The following macros do not require an argument. They can be used to locate a
variable in persistent data memory or in near data memory.
#define _PERSISTENT __attribute__((persistent))
#define _NEAR __attribute__((near))
For example, to declare two variables that retain their values across a device Reset:
int _PERSISTENT var1,var2;
10.3.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,
as well as temporary variables defined by the compiler.
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.
auto variables, as their name suggests, automatically come into existence when a
block is executed and then disappear once the block exits. Since they are not in exis-
tence for the entire duration of the program, there is the possibility to reclaim memory
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. The stack is discussed in
Section 10.3.2.1 Software Stack.
The the standard qualifiers: const and volatile may both be used with auto vari-
ables 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 mem-
ory on the stack, not in the program memory like with non-auto const objects.
10.3.2.1 SOFTWARE STACK
The dsPIC DSC device dedicates register W15 for use as a software Stack Pointer. All
processor stack operations, including function calls, interrupts and exceptions, use the
software stack. The stack grows upward, towards higher memory addresses.
The dsPIC DSC device also supports stack overflow detection. If the Stack Pointer
Limit register, SPLIM, is initialized, the device will test for overflow on all stack opera-
tions. If an overflow should occur, the processor will initiate a stack error exception. By
default, this will result in a processor Reset. Applications may also install a stack error
exception handler by defining an interrupt function named _StackError. See Chap-
ter 14. Interrupts for details.
The C run-time startup module initializes the Stack Pointer (W15) and the Stack Pointer
Limit register during the startup and initialization sequence. The initial values are
normally provided by the linker, which allocates the largest stack possible from unused
data memory. The location of the stack is reported in the link map output file.
Applications can ensure that at least a minimum-sized stack is available with the
--stack linker command-line option. See the MPLAB XC16 Assembler, Linker and
Utilities Users Guide (DS52106) for details.

- 1
- 2
…
- 145
- 146
- 147
- 148
- 149
…
- 365
- 366