These attributes are supported by the MSP430 back end:
critical ¶This attribute applies to functions.
Critical functions disable interrupts upon entry and restore the
previous interrupt state upon exit. Critical functions cannot also
have the naked, reentrant or interrupt attributes.
The MSP430 hardware ensures that interrupts are disabled on entry to
interrupt functions, and restores the previous interrupt state
on exit. The critical attribute is therefore redundant on
interrupt functions.
interrupt ¶This attribute applies to functions.
It indicates that the specified function is an interrupt handler. The compiler generates function entry and exit sequences suitable for use in an interrupt handler when this attribute is present.
You can provide an argument to the interrupt
attribute which specifies a name or number. If the argument is a
number it indicates the slot in the interrupt vector table (0 - 31) to
which this handler should be assigned. If the argument is a name it
is treated as a symbolic name for the vector slot. These names should
match up with appropriate entries in the linker script. By default
the names watchdog for vector 26, nmi for vector 30 and
reset for vector 31 are recognized.
reentrant ¶This attribute applies to functions.
Reentrant functions disable interrupts upon entry and enable them
upon exit. Reentrant functions cannot also have the naked
or critical attributes. They can have the interrupt
attribute.
wakeup ¶This attribute only applies to interrupt functions. It is silently ignored if applied to a non-interrupt function.
A wakeup interrupt function rouses the processor from any low-power state that it might be in when the function exits.
lower ¶uppereitherThese attributes apply to functions and variables.
On the MSP430 target these attributes can be used to specify whether the function or variable should be placed into low memory, high memory, or the placement should be left to the linker to decide. The attributes are only significant if compiling for the MSP430X architecture in the large memory model.
The attributes work in conjunction with a linker script that has been
augmented to specify where to place sections with a .lower and
a .upper prefix. So, for example, as well as placing the
.data section, the script also specifies the placement of a
.lower.data and a .upper.data section. The intention
is that lower sections are placed into a small but easier to
access memory region and the upper sections are placed into a larger, but
slower to access, region.
The either attribute is special. It tells the linker to place
the object into the corresponding lower section if there is
room for it. If there is insufficient room then the object is placed
into the corresponding upper section instead. Note that the
placement algorithm is not very sophisticated. It does not attempt to
find an optimal packing of the lower sections. It just makes
one pass over the objects and does the best that it can. Using the
-ffunction-sections and -fdata-sections command-line
options can help the packing, however, since they produce smaller,
easier to pack regions.
The lower attribute has some additional functionality when applied
to variables.
If -mdata-region={upper,either,none} has been passed, or
the section attribute is applied to a variable, the compiler
generates 430X instructions to handle it. This is because the compiler has
to assume that the variable could get placed in the upper memory region
(above address 0xFFFF). Marking the variable with the lower attribute
informs the compiler that the variable is placed in lower memory so it
is safe to use 430 instructions to handle it.
In the case of the section attribute, the section name given
is used, and the .lower prefix is not added.