My confusion over the term "Global" in reference to variables, objects, etc.

ElectricAye

Hi all,

I'm having trouble understanding exactly what "Global" means when it comes to the Propeller. Looking through the manual, I see where "global" appears to define something as being global TO AN OBJECT, which I suppose means that such a variable could be used anywhere and everywhere within an object, including the methods called by that object, but not outside of the object. (Should we call these quasi-global??? or wannabe-global???) And yet the System Counter is also considered "global" but it, I think, can be used truly anywhere and everywhere, in various objects, cogs , whatever, etc. If so, then what sort of variables are we talking about when you launch a method into a new cog? Are we entirely out of the global village then?

Do I have that right about global-icity, or is there more to this than I've described?

Are there any other definitions or uses of the term "global" when working with the Propeller?

thanks,
Mark

Mike Green

With Spin and the Propeller, "global" normally means global within an object. Everything except parameters and local variables declared in a method declaration are known throughout the object. One other exception is the local label starting or ending with ":".

An object's public methods (PUB) and constant definitions (CON) are available in other objects that include the object (with OBJ), but you have to use the object's name as a prefix ("xxx." or "xxx#" respectively).

jazzed

Global is a "scope rule" term and so is "local."

A global resource is directly available to any object method. CNT is global for example so is INA.
Any DAT variable is global by reference address but not by name between objects.

A local resource is available only to the "class" of processing element.
A variable declared for use in a method is local to the method and not directly accessible to other methods.
A VAR variable declared in an object is local to the object and not directly accessible to other methods objects.

Local object resources are called "members" of the "class" in other languages.
The "class" structure evolved to solve problems in programs developed by teams among other things.
It is very easy to accidently use the same name for certain kinds of methods, constants, and variables.
In C one has no choice than solving this problem by prepending names with the module name or abbreviation.

Hope this helps a little more.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Post Edited (jazzed) : 5/29/2009 7:32:03 PM GMT

localroger

@EA: Spin doesn't have what would normally be called "global" vars; those would be accessible to all objects, and Spin doesn't provide for anything like that. Spin VARs are global to the object in which they are declared, but are not accessible either to member objects included in OBJ, or higher up objects that include the one that declares the VARs. Spin "local" vars are the ones declared on a PUB or PRI line for use only in that routine.

Like leaving GOTO out, this is meant to enforce good habits; we don't have to worry that we will accidentally use the same variable name that's used for something else deep in the TV driver. But for some things it's a real nuisance.

While Spin lets you call a sub-object's methods by saying object.method(parms), and its constants by saying object#const, it does not provide for accessing another object's variables. So we have to use kludges like this:

pub read_myvar
  return myvar

so that the parent object can refer to object.read_myvar. If you have a lot of these it gets to be ridiculous, so the usual practice is to put your data in an array and just read the address:

var
  ' allmydata usage:
  ' 0 = X
  ' 1 = Y  etc.
  allmydata[noparse][[/noparse]12]

pub find_allmydata
  return @allmydata

Then the parent object can find, say, Y as

  allmydata_base := object.find_allmydata
  Y := long[noparse][[/noparse]allmydata_base] [noparse][[/noparse] 1 ]

After you do this twice you'll want to make it more readable

CON

  allmydata_x = 0
  allmydata_y = 1

  X := long[noparse][[/noparse]allmydata_base][noparse][[/noparse]allmydata_Y]

Finally, even this only works with sub objects that you can Tarzan through to get the address. If you need a common block of data to be shared by many objects spread across an application at different levels of abstraction, about the only thing left is the direct memory trick I mentioned in the other thread:

  word[noparse][[/noparse]$FFFE] := @allmydata

Now any object anywhere in the application can do this:

  allmydata_base := word[noparse][[/noparse]$FFFE]
  Y := long[noparse][[/noparse]allmydata_base][noparse][[/noparse]allmydata_Y]

BONUS: If you're doing direct memory access, and you have a long PASM function like say sdspifemto, once you start the PASM cog you can reclaim the PASM code DAT block hub RAM by accessing it directly. PASM is copied into cog RAM to run, after which, unless you have a need to restart the cog later, the original in Hub RAM is never used again. All you need to do is figure out how long the DAT block is (F8 is your friend) and provide for passing its starting address to whoever might need it either with a PUB function or by writing to raw RAM as shown above.

Post Edited (localroger) : 5/29/2009 5:25:14 PM GMT

jazzed

Nice, detailed, and helpful post localroger.

Not making an argument ... I would like to just point out, for those who may not know, one of the reasons for using an accessor method rather than having direct access to a variable is encapsulation. This is great for keeping users from abusing your variables and allows the convenience to the author for adding other code transparently if necessary for some follow-on product. Of course if you want to expose your variables via an array that's fine. I loathe that Spin does not formalize this with "public" attributes in a similar way that many OOP languages do, but I'll get over it [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

ElectricAye

WOW!

Okay, this is a lot of information. And I want to thank everyone for their detailed responses. It's going to take me a while to absorb this, however.

You guys are awesome!

thanks so much,