Propeller Manual

LONG – Spin Language Reference
and longs relate to each other, but it may prove problematic when thinking of multiple items
of a single size, like longs.
For this reason, the
LONG designator has a very handy feature to facilitate addressing from a
long-centric perspective. Its BaseAddress field when combined with the optional Offset field
operates in a base-aware fashion.
Imagine accessing longs of memory from a known starting point (the BaseAddress). You
may naturally think of the next long or longs as being a certain distance from that point (the
Offset). While those longs are indeed a certain number of “bytes” beyond a given point, it’s
easier to think of them as a number of “longs” beyond a point (i.e., the 4
th
long, rather than
the long that starts beyond the 12
th
byte). The LONG designator treats it properly by taking the
Offset value (units of longs), multiplies it by 4 (number of bytes per long), and adds that
result to the BaseAddress to determine the correct long of memory to read. It also clears the
lowest two bits of BaseAddress to ensure the address referenced is a long-aligned one.
So, when reading values from the
MyData list, long[@MyData][0] reads the first long value and
long[@MyData][1] reads the second.
If the Offset field were not used, the above statements would have to be something like
long[@MyData], and long[@MyData+4], respectively. The result is the same, but the way it’s
written may not be as clear.
For more explanation of how data is arranged in memory, see the
DAT section’s Declaring
Data(Syntax 1) on page 100.
An Alternative Memory Reference
There is yet another way to access the data from the code example above; you could
reference the data symbols directly. For example, these statements read the first two longs of
the
MyData list:
Temp := MyData[0]
Temp := MyData[1]
So why wouldn’t you just use direct symbol references all the time? Consider the following
case:
Temp := MyList[0]
Temp := MyList[1]
Page 132 · Propeller Manual v1.1