When to use VAR and when to use DAT?

port513

I know it should be easy to understand this but I really can't get it.

If I want a variable reachable from anywhere, is it in VAR och DAT I should put it?
If I want a variable that I can write/read from any cog, where do I put it?

Short question, when to use DAT and when to use VAR?


And yes I have read the manual about VAR and DAT blocks but I think I need some help here.


/Henke

hippy

Either of the two -

VAR long myVar

DAT myVar long 0

Will create a variable 'myVar' which is accessible by the Spin object / main program it is defined in, and any methods of that which are launched to run in separate Cogs.

The difference comes when the variable is in an Spin program which is used as a sub-Object more than once. For VAR, every sub-object will have its own instance of "myVar", for DAT they will each refer to the same variable.

Which you need depends on what you are trying to achieve. If each is counting how many times a signal is received say, they will likely want VAR so each count is independent of the other counts. If they were each updating a total of any signals received a single DAT would do that ( you need to to take care to prevent simultaneous updating from multiple Cogs ).

port513

So for inter cog communication I can use VAR and DAT to count instances of an object, right?

If cog1 have done something that it needs to send to cog2 it can write that to VAR long cog1Var and cog2 can read it from there, right?

And if I need to keep track of number of instances of my new object I use the DAT section, right?



/Henke

hippy

DAT can be used to count instances of an object.

Either VAR or DAT can be used to pass data between cogs if those cogs are launched in the same object ...

VAR
  long countervar

  long astack[noparse][[/noparse] 100 ]
  long bstack[noparse][[/noparse] 100 ]

DAT
  counterdat long 0

PUB Main
  CogNew( a, @astack )
  CogNew( b, @bstack )

PRI a
  countervar++
  counterdat++

PRI b
  countervar++
  counterdat++

Both 'a' and 'b' have access to 'countervar' and 'counterdat', so their values will go up twice as fast as when only one or the other cogs were running.

Phil Pilgrim (PhiPi)

It may be helpful to picture this hierarchy (top to bottom):

1. DAT variable: global to all instances of an object and all its methods. Can take on any initial value declared with a LONG, WORD, or BYTE pseudo-op.

2. VAR variable: local to each instance of an object; global to all its methods. Gets initialized to zero.

3. Method variable: local to the method it's declared in. Initial value is undefined.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

port513

So for normal use I can use VAR to store instance local variable and if I need to have a instance global I use DAT, right?

Is there any other good reason to use DAT vs VAR besides that DAT can predefine a variable and store tables etc?



/Henke

Phil Pilgrim (PhiPi)

A DAT variable will be global to all instances of the object that defines it. In other words, there's only one copy. A change made to a DAT variable by one instance is a change made for all instances. VAR variables are replicated in each instance of the object that defines them. Changes made by one instance have no effect on the same variable in another instance.

DAT variables, as Hippy explained above, can be used to count instantiations of an object. They can also be used for communication between separate instances of the same object. These are just two examples that go beyond predefinition and table storage.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

port513

So if I have a main program and a VAR variable declared I don't need to put that variable in DAT if all of my methods launched in other cogs belong to this main program?



/Henke

hippy

That's correct. You can if you want to but you do not have to.

port513

Hehe, now I'm confused! [noparse];)[/noparse]

So when do I use DAT then? (except for tables and predefined variables)

Any rules here or I can use it as I like?

Can I use memory more effective by using DAT och VAR?



/Henke

hippy

It doesn't usually matter which you use and you can usually use them as you like.

It's only when you are dealing with sub-objects does how the variables are defined really matter; VAR if you want to have each variable unaffected by the same named variable in another Cog, and DAT if you want all Cogs to use the same single variable.

The best rule is perhaps : Use VAR, except when you specifically need to use DAT.

Once you've gained experience and are more familiar with Spin it should all become a lot clearer. Use VAR by default and when you need to use DAT should become obvious. I would venture that most objects do not need to use variables in DAT.

Phil Pilgrim (PhiPi)

hippy said...
VAR if you want to have each variable unaffected by the same named variable in another Cog, and DAT if you want all Cogs to use the same single variable.

This applies to multiple instances of an object in the same cog, too. VARs are also replicated there as, for example, in an object array.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

port513

Thanks for your patience!

/Henke

Ken Peterson

Another use for variables in DAT: setting up parameters for a PASM routine. The manual talks about passing the PAR parameter to your cognew routine to serve as a pointer for your PASM code to access a HUB variable. However, you can set up all kinds of pointers to VAR or DAT variables in DAT next to your PASM code to be used by your PASM routine.

1. Define your variables (VAR or DAT)
2. Define your pointers (longs in DAT placed within 496 longs of the start of your PASM routine)
3. Call an initialization routine in SPIN that sets the pointers to point to the variables, i.e., var_ptr1 := @var1, etc.
4. Start your PASM routine with COGNEW() - your initialized pointers will be loaded into the cog along with your code!
5. After the cog starts, your pointers will be local to the cog only. Subsequent changes to the pointer values in DAT will not be reflected in the cog. They are copies. However, your cog will have read and write access to your variables via the pointers.· Since your variables will never move in memory, your pointers·are not likely to change anyway (see exception below).
6.· If you have multiple instances of an object that has a PASM routine, each instance will have to call that initialization routine to·set the pointers to variables in·its own VAR section before calling COGNEW() to start the PASM cog.· This is the case where the pointers in DAT would actually change.
7.· You can use DAT variables to pass other parameters to your PASM routine as well.·· Just remember that they are copies (passed by value, not by reference).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."

- Bjarne Stroustrup

Post Edited (Ken Peterson) : 9/25/2008 1:06:50 PM GMT

Cluso99

Ken

"I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone."
- Bjarne Stroustrup

I couldn't resist... and my tv, video recorder... even the toaster is going that way :-(