General Questions/Statements

eldonb46

As a new user of the Propeller, I think I have come to the following general conclusions:

Please help; Are the following statements true for a general Spin Programming strategy?

1. A Parent Object can call any Child Object's PUB Method.
2. A Parent Object can NOT "directly" call a Grandchild's PUB Method.
3. A Child Object can NOT call a Parent or Grandparent's Method.
4. An Object can NOT contain a Parent or Grandparent Object (error: circular reference).
5. A Child Object can NOT call a Sibling's Method.
6. A COG can NOT call it's Parent's Child COG's Method (see previous point).
7. A COG can call it's spawning-Objects Methods
8. A COG can call it't spawning-Objects Child Methods
9. Except for a single task, Child COG needs to be set up as a Server.
10. An Object contained in Two other Objects is not a single Object, but will be clones with separate variable space.

To help me as a new user, are other (short) strategy statements that could or should be added.


Note: Considering the above, I suspect the COG #8 is almost never used by most Spin Programmers.



Please help my (our) understanding as a new user.

Thanks
eldonb46

StefanL38

This maybe sounds strange. Never cared much about thinks like that. I'm just coding.
1,2,3 yes
4 why should I code this way?
5 what's a sibling's method?
6 what's a spawning object?

9 what's in this case a server and what's the difference to a "client"

best regards
Stefan

Phil Pilgrim (PhiPi)

eldonb46,

Welcome to the forum!

1,2,3,4: true
5: false You can call a sibling's public methods if the sibling object is declared in the OBJ section, as long as the sibling does not call yours, since there's no circular dependency.
6: false, under the same circumstances that 5 is false. (They're actually the selfsame statements.)
7, 8: I don't understand "spawning" in this context.
9: Half true. An object's VAR variables are cloned. Everything else exists as a single instance.

-Phil

eldonb46

Phil Pilgrim (PhiPi) wrote: »

eldonb46,

7, 8: I don't understand "spawning" in this context.

-Phil

Thanks, I think I see the problem with my statement, and
Perhaps I am using the wrong word here: spawn ~= A method that calls cognew

main
+ child obj
+++ cognew A
+++++ cognew B


I think I understand, because both cogs would be from the same Parent Object, they would be siblings regardless of how they were created (spawned). And they can call their Parent Object Methods?

Are these now correct?

7. A COG can call it's Parent-Objects Methods
7.5. A COG that creates a new COG, creates a Sibling
8. A COG can call it't Sibling's Methods


Obviously this is still a little confusing to me.

Thanks for all of helpful comments
eldonb46

Mike Green

You really need to separate the notion of parent - child from the notion of "spawning" a new cog. You can have a complex program with lots of objects and methods referred to all over the place and it all runs on a single cog with nary a COGNEW anywhere. You can also have a program that doesn't use any objects, yet starts up code in all the available cogs, maybe even stops cogs and starts up new code in the cogs over an over again. Your questions 7-8 don't make sense since cogs don't have parents or children.

cavelamb

It sounds more and more like a scope question.
Can code running in one cog access data or code (methods) in another.

Mike Green

Each cog executing Spin code has its own stack. For the initial (main) cog, the stack begins at the end of the program and extends upward in memory. For all other cogs, a stack area is supplied with the COGNEW or COGINIT. There's no checking for the end of the stack area. Stacks are always initialized to contain a stack frame with a return address to a COGSTOP statement for the cog. From that point on, the cog has access to any methods that are accessible from the method whose call is supplied in the COGNEW / COGINIT statement. A cog has access to any data accessible from the code being executed. Using BYTE[], WORD[], and LONG[], a cog can access any location in hub RAM or ROM. Other than the predefined I/O registers, cogs running Spin have no access to the memory of the cog itself since the Spin interpreter occupies the whole cog.

If you start up an assembly language program in a cog, that program has complete access to the cog, its memory, its I/O registers, and all of the hub RAM and ROM. It has no access to the memory of any other cog. The only thing it can do to another cog is reset it (using COGSTOP) or start up a new assembly or Spin program in that cog.