OBJ's method need to call method in the ROOT

ALIBE

Hello All, It's been a while since I last visited our forum. Been traveling a lot on work. It's good to be back!

I searched the forum and could not find pointers to this sort of a question.· If this was already answered, my apologies for the redundancy - please point me there.

I have a scenario where the "main" entry point .spin file has a couple of methods ::GetAccessToSensoryData() and ::ReleaseAccessToSensoryData(). This file also has a few "OBJ" refs to various "Child" level .spin files.· Now, I want my "Child" level .spin to be able to call these two methods.

Obviously, I can't do a circular reference w/i my child code; and I'm not sure how I would Fully Qualify the method in the child before calling it.

Any pointers would be great.

Thanks in advance




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."


ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·

Mike Green

This is really a mess to try to do most of the time. A lot depends on whether these routines have to have global data and whether only one child object has to reference them or several child objects need to do this. Basically, you have to move the routines to the child or, if the routines need to be referenced by several child objects, make them a grandchild-like object. If they need to access global data in the main object, you may have to pass the address of the data as a parameter to them. You can't have global data in the object itself, because there'll be a separate data area for each OBJ declaration in your overall program and that's probably not what you want. The object byte code itself is not supposed to be duplicated.

ALIBE

thanks Mike. I 'll play w/ this a bit - the Grandchild route might work


wrt the Global variables,
Since Global Variables cannot be passed are NOT visible across OBJects, the term "Global" really only means "Private" to that mod.

In my case, a few individual objects are running on a separate Cog. And, each of these individual Cog'd objects will need to access my global variables. However, inherently, they are unable to. I shall try send the address of the global variables to the ::Start method at the time of CogNew.

Not sure off that top of my head if that route will work

- do you ?

thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."


ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·

Mike Green

Alibe,
That's basically what I've done in the Propeller OS although, rather than passing the address to the start method, I've allocated work areas in the high end of RAM and have a small table of pointers to the work areas right at the upper end of RAM at fixed locations (like $7FFC, etc.)

ALIBE

Thanks Mike. I should at least check out your O/S to understand it better. I should be honest, I've never tried it.

On this topic of Global variables and access to them, I see the architecture rendered its current behavior. I do however, have a hard time understanding why Parallax chose that route of limiting access to GVs to container objects. When multiple COGs are able to access the GVs, multiple objects living in a COG are unable to.

If Parallax are able to make this change in the future revs - not sure how they'd do it (I'm only a feature guy), this might be a good one to cover.

not sure if Parallax teams have any thoughts on this.

Thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."


ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·

ALIBE

Thanks Mike. I should at least check out your O/S to understand it better. I should be honest, I've never tried it.

On this topic of Global variables and access to them, I see the architecture rendered its current behavior. I do however, have a hard time understanding why Parallax chose that route of limiting access to GVs to container objects. When multiple COGs are able to access the GVs, multiple objects living in a COG are unable to.

If Parallax are able to make this change in the future revs - not sure how they'd do it (I'm only a feature guy), this might be a good one to cover.

not sure if Parallax teams have any thoughts on this.

Thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."


ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·

rokicki

I have posted a "Singleton" object (do a search from search.parallax.com) that will allow you to have top level routines
callable from any number of low-level objects, all sharing that same top object. It's a bit of a hack and there are
often other ways around it, but it does work. (It works by "patching up" the spin bytecodes at runtime).

ALIBE

Rockiki, thank you - will give that a shot.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."


ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·