Range of Variables

The range and nature of each type of variable is as follows:

• BYTE – 8 bits (unsigned); 0 to 255.
• WORD – 16 bits (unsigned); 0 to 65,535.
• LONG – 32 bits (signed); -2,147,483,648 to +2,147,483,647.

For more details regarding their range and usage, see BYTE, WORD, and LONG.

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 , 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 and PRI.

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 for examples.