122-32000 Parallax Inc, 122-32000 Datasheet - Page 129

• Manufacturer Part Number: 122-32000
• Description: MANUAL PROPELLER
• Manufacturer: Parallax Inc

Specifications of 122-32000

• Accessory Type: Manual
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant
• For Use With/related Products: Propeller Education (PE) Kit
• Lead Free Status / Rohs Status: Lead free / RoHS Compliant

3: Propeller Programming Tutorial
The top part of the window is the Info Object View; it is similar to the Object View. The
center part of the window shows the application’s RAM Usage. Notice that the “Program”
(the compiled source code) itself consumes 68 longs of RAM and the “Variable” (the global
variables) consumes 10 longs of space.
Now, close this window and change the object block back to the way it was, specifying six
instances of the Output object;
. Compile and view info again (F8 or Run
LED[6] : "Output"
→ Compile Current → View Info…). Notice that now the program consumes 73 longs of
RAM and the variable space consumes 60 longs. This is only 5 additional longs of program
space but 50 additional longs of variable space. The extra program space is just overhead to
deal with five additional objects but the variable space is six times its previous size; each
object has its own global variable space. Our Blinker2 object doesn’t define any global
variable space, but Output defines nine longs for
and one byte for
for a total of 10
Stack
Cog
longs of space since an object’s variable space is always long-aligned.
In the Object Info window, you can also click on the Output object to see how much space
each individual instance of that object consumes. We can see that Output’s program size is
21 longs and variable space is 10 longs.
Object Lifetime
When applications are compiled a binary image of the executable code is created. That
binary image is what is actually downloaded into the Propeller and is usually what we are
referring to when we say “application” or “Propeller Application.”
The compiled code for each object used by an application is included within that binary
image along with variable space for each instance of each of those objects.
During run time, the application may use any object for any amount of time; some may be
used always and others only on occasion but all are consuming a static amount of memory for
their code and variables.
For developers accustomed to programming with objects on a computer, this is an important
concept to understand. On the Propeller an object’s lifetime is static; whether or not it is
actively in use at the time, it always requires a specific amount of memory in the
application’s binary image. On desktop/laptop computers, objects require a dynamic amount
of memory because they are “created” and “destroyed” during the run-time process as is
needed. On the Propeller, the objects are “created” at compile time and are never “created”
or “destroyed” at run time because the act of doing so would fragment memory and cause
indeterministic behaviour in real-time embedded systems.
Propeller Manual v1.0 · Page 129