Difference between VAR and DAT

andrewsi · 2010-10-23 00:22

I'm working on my first project and have encountered some odd behavior where I have a freerunning cog from a secondary object measuring pulse widths, and it's returning the pulsewidths back to the main program object by writing to that long... e.g.:

In the secondary object, in a new cog:

PUB func (pulsewidth) 'called as func(@pulse)
...
LONG[pulseWidth] := tempcount

What I seem to be finding is a difference in behavior between VAR and DAT as the main program's "holder" for returning values from the free running cog. I think that if "pulse" is defined as a var, it's never getting written by the measuring cog, but if pulse is defined as a long in a DAT block instead, then it works.

The manual is not super clear on this point, but it looks like a DAT block is just a set of VARs where you get to preinitialize it with data. I think I must be fundamentally misunderstanding something, though, about scope and accessibility of VARs from other objects, even if passed by reference.

If anybody can enlighten me on the subtleties, (or really, on the recommended means of passing data asynchronously from a cog running in the context of one object to a cog running in the context of a different object), that would be greatly appreciated.

Thanks for helping with my newbie question!

Andy

Heater. · 2010-10-23 00:34

First thing is that it is possible to use the same object twice in your program.

In which case there will be multiple copies of your variables in the VAR section created. One copy per instance of the same object.

BUT there will only be one copy of the DAT variables. That copy is shared among all instances of the object.

Perhaps this detail does not apply to you as you only have on instance of each object.

In that case we probably need to know more about what you are doing, and see the complete code to be able to help.

andrewsi · 2010-10-23 00:38

The manual on VAR does say that you can pass global variables to another object as long as you do it by address. I believe I was doing that. However, since DAT seems to be working for my purposes, it's probably not worth posting the lengthy code here to try to find the exact problem.

It may, perhaps, be related somehow to the fact that the call to the "Start" method in the subobject was by reference, but then the cognew operation in that method simply passes the parameter on to the actual method that does the writing back to the original address. I figure since what the parameter contains is the address of the global variable, that passing THAT on by value to the newly started cog should be perfectly fine, since the address to write back to hasn't changed. (And, this is working for a DAT address if not for a VAR one.)

Anyway, thanks for the ideas.

Heater. · 2010-10-23 00:57

andrewsi,

I figure since what the parameter contains is the address of the global variable, that passing THAT on by value to the newly started cog should be perfectly fine

If I undestand correctly what you are saying then I think you are quite right in that assumption.

For sure passing VAR addresses, obtained with @, around should work. In my ZOG emulator, for example, I have:

VAR
  '8 consecutive longs for Zog's par block.
  long par_zpu_memory_addr
  long par_zpu_memory_sz
  long par_initial_pc
  long par_initial_sp
  long par_dispatch_tab_addr
  long par_pasm_addr
  long par_zog_mbox_addr
  long par_vm_mbox_addr

And then use it to start a COG so:

PUB start
'bla
'bla
zog.start(@par_zpu_memory_addr)

zog.start then starts some PASM in a COG passing that parameter on via PAR.

mpark · 2010-10-23 08:55

andrewsi wrote: »

... However, since DAT seems to be working for my purposes, it's probably not worth posting the lengthy code here to try to find the exact problem.

From what you've said, VAR should work too. Something is fishy. I think you should post your code, though if it's lengthy, please cut it down as much as possible.

Difference between VAR and DAT

Comments