Propeller Manual

VAR – Spin Language Reference
Page 212 · Propeller Manual v1.1
Organization of Variables
During compilation of an object, all declarations in its collective
VAR blocks are grouped
together by type. The variables in RAM are arranged with all the longs first, followed by all
words, and finally by all bytes. This is done so that RAM space is allocated efficiently
without unnecessary gaps. Keep this in mind when writing code that accesses variables
indirectly based on relative positions to each other.
Optimized Addressing
In the compiled Propeller Application, the first eight (8) global long-sized variables are
addressed using an optimized encoding scheme. This means accessing the first eight global
long variables takes slightly less time than accessing the ninth, or later, long variables. Word
and byte variables do not have an optimized addressing scheme. To optimize execution
speed, ensure that all global variables used by the application's most repetitive loops are
among the first eight longs. A similar mechanism applies to local variables; see the
PUB
section, page 185, for more information.
Scope of Variables
Symbolic variables defined in
VAR blocks are global to the object in which they are defined
but not outside of that object. This means that these variables can be accessed directly by any
public and private method within the object but those variable names will not conflict with
symbols defined in other parent or child objects.
Note that public and private methods also have the ability to declare their own local variables.
See
PUB, page 182, and PRI, page 181.
Global variables are not accessible outside of an object unless the address of that variable is
passed into, or back to, another object through a method call.
Scope Extends Beyond a Single Cog
The scope of global variables is not limited to a single cog either. An object’s public and
private methods naturally have access to its global variables regardless of what cog they are
running on. If the object launches some of its methods into multiple cogs, each of those
methods, and thus the cogs they are running on, have access to those variables.
This feature allows a single object to easily manage aspects of multiple processes in a
centralized way. For example, a sophisticated object may take advantage of this to instantly
affect “global” settings used by every multi-processed code entity that it created.
Of course, care should be used to ensure that multiple processing on the same block of
variables does not create undesirable situations. See
LOCKNEW on page 122 for examples.