Yet another shared variables post...
James Newman
Posts: 133
I've been looking for a thread or something that explains all of the possible ways to share values between cogs, and between spin and asm. I'm sure there are pelnty of places where it's been discussed, and I can find several threads that touch on parts of it all, but I have yet to find a place that lists the options and methods all together.
The following thread answered a few of my questions, but I still have one.
http://forums.parallax.com/forums/default.aspx?f=25&m=200240
Ok, I see how some of the basics work.
1) Cog2Cog both running Spin. If they're in the same object, they can both access the variables in the VAR section just fine.
2) Cog2Cog one running Spin, the other assembly. The address of a VAR section variable can be passed via CogInit or CogNew into the PAR register. The Spin cog can still access this memory as normal, and the asm cog can access is through HUB access commands.
3) Cog2Cog both running asm. As in situation #2, the variable is declared in the Var section, and the address is passed to both asm cogs, they can both access the memory like the asm cog in situation #2.
These are the conclusions I've come to:
-CON Section 'variables' are constant. They can be accessed by Spin in the same object directly. They can be accessed by other objects through an <object>.<constant> fashion. They must be given a value upon compilation. Their value can not change during runtime. ?They exist in HUB RAM as separate constant values for every place they're used?
-VAR Section variables are in HUB RAM. They can be accessed by Spin in the same object directly. ?Are they accessible by other objects through the <object>.<variable> method? They can be accessed by other objects through get/set functions called via the <object>.<function> syntax. They can be accessed by ASM through HUB access functions if the address is known. This address can be passed via CogInit or CogNew into the PAR register. They cannot be initialized to a specific value, but they will be set to 0 automatically. They can be changed during runtime. They exist in HUB RAM. The exact memory location of these variables will be rearranged at compile time to adhere to the following order: Longs, Words, Bytes.
-DAT Section variables declared via <type> <name> are similar to VAR section variables. ?They can be used by spin in the exact same manner? If their address is passed to an asm cog, they can be accessed exactly in the same manner as Var Section variables, as well. They exist in HUB RAM, and they can change value durring run time. Differences: They can be initialized, ?and must be?. They are not rearranged to meet the order stated earlier, but are padded to meet Long address alignments. And the tricky part... If an assembly cog is launched containing these, it reserves space in COG RAM, and fills this space with the values in HUB RAM at that time. This allows for the values to be changed via Spin, then passed along to COG RAM when an assembly cog is launched. The former HUB RAM remains like a VAR Section variable. The COG RAM variables are accessible directly by the asm cog, and are independent of the HUB RAM ones after the cog is launched. Any change to them will not be reflected in HUB RAM, and cannot be accessed by another cog (running spin or asm). Several asm cogs can be launched with these, each will have their own copies of COG RAM reserved, and each will be filled with the values in HUB RAM at that time, in runtime.
-DAT Section variables declared via RES. These are COG RAM variables. ?They can not be initialized? Several asm cogs can be launched with these, each will have their own copies of COG RAM reserved. They can be changed at runtime. They cannot be accessed by another cog, and will have no affect on HUB RAM.
-Local Variables for Spin Functions. These are HUB RAM variables. They are allocated out of a 'stack' of HUB RAM. If this function was launched into a cog: This must exist in HUB RAM somewhere and the address of it passed to CogInit or CogNew. These local variables follow the same rules as all other HUB RAM, but this area of memory can be allocated for other local variables later, or for storage of values during expression computations, so accessing it for another cog is almost always a bad idea. The stack will probably be declared in the VAR section of a section of Spin code somewhere. (IE in the Spin section of an object that launched the cog.) I suppose the stack could be declared in the DAT section using the <type> <name> syntax, but would have no logical purpose for the COG RAM allocated with it? ?I'm not sure where the stack HUB RAM for the initial running cog comes from... I've read it somewhere but don't remember it...?
If someone more organized than myself could add any more information, verify/correct what I have, and organize it all into a table or chart, I think it would be useful. The confusion isn't in HUB RAM and COG RAM... IMO... but more in how the compiler decides where things are allocated. Also, alot of this information exists in documentation and on these forums, but I have yet to see it all in one place. If it does exist, I've just missed it.
Finally, how does the CON Section and asm launched cogs behave? I just tried to use a constant in the CON section in some asm code, and failed. I tried
CON _TEST_CON = 96
...
mov temp,_TEST_CON
and also
CON _TEST_CON = 96
...
mov temp,_#_TEST_CON
both 'crashed' my display, so I think both corrupted memory somewhere, where a simple
mov temp,#96
works fine.
The following thread answered a few of my questions, but I still have one.
http://forums.parallax.com/forums/default.aspx?f=25&m=200240
Ok, I see how some of the basics work.
1) Cog2Cog both running Spin. If they're in the same object, they can both access the variables in the VAR section just fine.
2) Cog2Cog one running Spin, the other assembly. The address of a VAR section variable can be passed via CogInit or CogNew into the PAR register. The Spin cog can still access this memory as normal, and the asm cog can access is through HUB access commands.
3) Cog2Cog both running asm. As in situation #2, the variable is declared in the Var section, and the address is passed to both asm cogs, they can both access the memory like the asm cog in situation #2.
These are the conclusions I've come to:
-CON Section 'variables' are constant. They can be accessed by Spin in the same object directly. They can be accessed by other objects through an <object>.<constant> fashion. They must be given a value upon compilation. Their value can not change during runtime. ?They exist in HUB RAM as separate constant values for every place they're used?
-VAR Section variables are in HUB RAM. They can be accessed by Spin in the same object directly. ?Are they accessible by other objects through the <object>.<variable> method? They can be accessed by other objects through get/set functions called via the <object>.<function> syntax. They can be accessed by ASM through HUB access functions if the address is known. This address can be passed via CogInit or CogNew into the PAR register. They cannot be initialized to a specific value, but they will be set to 0 automatically. They can be changed during runtime. They exist in HUB RAM. The exact memory location of these variables will be rearranged at compile time to adhere to the following order: Longs, Words, Bytes.
-DAT Section variables declared via <type> <name> are similar to VAR section variables. ?They can be used by spin in the exact same manner? If their address is passed to an asm cog, they can be accessed exactly in the same manner as Var Section variables, as well. They exist in HUB RAM, and they can change value durring run time. Differences: They can be initialized, ?and must be?. They are not rearranged to meet the order stated earlier, but are padded to meet Long address alignments. And the tricky part... If an assembly cog is launched containing these, it reserves space in COG RAM, and fills this space with the values in HUB RAM at that time. This allows for the values to be changed via Spin, then passed along to COG RAM when an assembly cog is launched. The former HUB RAM remains like a VAR Section variable. The COG RAM variables are accessible directly by the asm cog, and are independent of the HUB RAM ones after the cog is launched. Any change to them will not be reflected in HUB RAM, and cannot be accessed by another cog (running spin or asm). Several asm cogs can be launched with these, each will have their own copies of COG RAM reserved, and each will be filled with the values in HUB RAM at that time, in runtime.
-DAT Section variables declared via RES. These are COG RAM variables. ?They can not be initialized? Several asm cogs can be launched with these, each will have their own copies of COG RAM reserved. They can be changed at runtime. They cannot be accessed by another cog, and will have no affect on HUB RAM.
-Local Variables for Spin Functions. These are HUB RAM variables. They are allocated out of a 'stack' of HUB RAM. If this function was launched into a cog: This must exist in HUB RAM somewhere and the address of it passed to CogInit or CogNew. These local variables follow the same rules as all other HUB RAM, but this area of memory can be allocated for other local variables later, or for storage of values during expression computations, so accessing it for another cog is almost always a bad idea. The stack will probably be declared in the VAR section of a section of Spin code somewhere. (IE in the Spin section of an object that launched the cog.) I suppose the stack could be declared in the DAT section using the <type> <name> syntax, but would have no logical purpose for the COG RAM allocated with it? ?I'm not sure where the stack HUB RAM for the initial running cog comes from... I've read it somewhere but don't remember it...?
If someone more organized than myself could add any more information, verify/correct what I have, and organize it all into a table or chart, I think it would be useful. The confusion isn't in HUB RAM and COG RAM... IMO... but more in how the compiler decides where things are allocated. Also, alot of this information exists in documentation and on these forums, but I have yet to see it all in one place. If it does exist, I've just missed it.
Finally, how does the CON Section and asm launched cogs behave? I just tried to use a constant in the CON section in some asm code, and failed. I tried
CON _TEST_CON = 96
...
mov temp,_TEST_CON
and also
CON _TEST_CON = 96
...
mov temp,_#_TEST_CON
both 'crashed' my display, so I think both corrupted memory somewhere, where a simple
mov temp,#96
works fine.
Comments
2) VARiables are accessible (by name) only within the object where they are declared. You can have a method in that object that returns the address of a variable and other objects can pass around that address and access the memory where that variable is stored using the address.
3) For each instance declared of an object, there is a separate VARiable area. There is only one DAT area for any object and only one copy of each of the methods of the object no matter how many instances there may be.
4) As you mentioned, local variables are allocated on a stack that normally runs from the end of the program to the end of RAM memory. If cogs are started using COGINIT/COGNEW, a stack area must be provided and that is what is used for the local variables for any methods executed by that cog.
5) Cogs are initialized by copying a 512 long area from main RAM to the cog's memory. The actual locations used by the assembly program are those in the cog's memory. The RES statement simply marks where in the cog's memory the variable would reside and doesn't use up a location in main RAM. Since the whole block of 512 longs is copied no matter how much is actually used, the locations corresponding to the RES statement actually do contain information, but it's whatever might occupy the location in main RAM. This might be some Spin code or other DAT information or a VAR area. An area reserved with RES statements has initially undefined content.
6) You can certainly use named constants from a CON section in your assembly code. Make sure what you write makes sense. In the example you showed, you had CON _TEST_CON = 96. You can write MOV temp,#_TEST_CON and that will work as you might expect. Note where the # is.
Post Edited (Mike Green) : 11/28/2007 5:05:48 AM GMT
I think this is a good arrangements of "things to know about data". There are only a few minor misunderstandings.
I should like to use your text - as it gives a nice framework - for my own dark purposes. I shall modify (improve?) it, and post it tonight (UMT).
You are damned right some synopsis was missing all along to help the newbies..
deSilva> Feel free to modify/improve it. I was basically trying to get it all set right in my own mind when I wrote that. I think it would be nice to have this scattered information, concerning data, collected and organized into a reference.