Shop OBEX P1 Docs P2 Docs Learn Events
Using VAR or DAT for variables — Parallax Forums

Using VAR or DAT for variables

shanghai_foolshanghai_fool Posts: 149
edited 2009-01-21 04:00 in Propeller 1
Is there a particular advantage of one or the other method of using variables?

I would like to reserve space in the main spin method for global variables that will be written by·some cogs and read by still other cogs. Can DAT variables be ORG'ed at a certain address in spin?
·

Comments

  • KyeKye Posts: 2,200
    edited 2009-01-20 02:43
    Both are pretty much the same. The same spin operators apply to both.

    I'm not sure how to set a memory location however.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nyamekye,
  • mirrormirror Posts: 322
    edited 2009-01-20 02:58
    VAR and DAT variables are *very* different.

    Although they are used (in terms of operators) in the same way, the reason for picking one over the other is totally unambiguous.

    If an object is included from multiple spin files, then every instance of that object will have unique VAR variables, but the DAT variables are common to all the instances of the object. If *all* of the variables are in DAT space, then it is possible to make objects which look and behave like they can be included in multiple parent objects.

    I believe the first example of this kind of multi-include object was my own SerialMirror obex.parallax.com/objects/189/. SerialMirror is a variation on FullDuplexSerial that gave access to the serial port from multiple different objects.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • RaymanRayman Posts: 14,597
    edited 2009-01-20 03:06
    I believe another difference is that the compiler has a nasty habit of reordering your VAR variables so that longs come first, then words, then bytes. But, I don't think the compiler reorders the variables in the DAT section, just aligns them to long, word or byte boundaries in a not so obvious way...

    If you plan on multiple instances of an object, you should definitely use the VAR section to save memory.

    Otherwise, what I do is try to keep any variable with an initial condition in the DAT section and general purpose working variables in the VAR section.
  • shanghai_foolshanghai_fool Posts: 149
    edited 2009-01-20 03:24
    Thanks for the responses.
    My main concern is for global variables. I will read RC receiver pulses in one cog but they will be read by other cogs for different purposes. I will only be sourcing the data from one object but that data may be read/utilized by other/multiple objects. For each object, I only need to pass the starting address of its range of variables but their structure will be dictated by the main/startup cog and all of its DAT will be in main memory.
    I just want to be sure I am going down the right path.
  • Andrew E MileskiAndrew E Mileski Posts: 77
    edited 2009-01-20 21:05
    Use DAT for anything global, VAR for anything local.

    The one exception being ASM, where each cog can have a local copy of the DAT, and can access the global hub DAT as well.

    As others have stated, every instance of an object gets a copy of VAR (copies are created on the stack), but all share the same DAT. Since VARs exist on per-instance stacks, and the compiler re-orders them too, they are really hard to access globally.

    Post Edited (Andrew E Mileski) : 1/20/2009 9:10:31 PM GMT
  • BradCBradC Posts: 2,601
    edited 2009-01-20 22:38
    Andrew E Mileski said...

    As others have stated, every instance of an object gets a copy of VAR (copies are created on the stack), but all share the same DAT. Since VARs exist on per-instance stacks, and the compiler re-orders them too, they are really hard to access globally.

    "really hard to access globally"? In what way? Worst case you have a method in the object to return the address of the variable you want to access. Easy way is just to use setters/getters from Spin.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cardinal Fang! Fetch the comfy chair.
  • Andrew E MileskiAndrew E Mileski Posts: 77
    edited 2009-01-21 01:47
    BradC said...
    "really hard to access globally"? In what way? Worst case you have a method in the object to return the address of the variable you want to access. Easy way is just to use setters/getters from Spin.

    If you have the address of the variable, it's a no brainer. And if you have the source, then ya, adding in "setters / getters" if they don't exist makes it easy.

    I was thinking of an extreme case of going through the SPIN bytecode of the objects in hub memory to find the stack with the variable in question. An unusual mindset brought on by study of SPIN bytecode I'm currently doing. Sorry.
  • KyeKye Posts: 2,200
    edited 2009-01-21 03:42
    Since this discussion is up right now... is there any way to gain acess to the variables within one spin file from another?

    I need my video driver to acess the mouse absolute x and y positions in my mouse driver. However, I would need to include a method that just returns the variables address. Is their any more elegant way to get arround this and driectly get addresses of the variables?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nyamekye,
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-01-21 03:49
    If you are looking at the spin bytecodes, look at the Spin Interpreter faster thread (see my index below for pointers). I put together info there from many sources)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Prop Tools under Development or Completed (Index)
    http://forums.parallax.com/showthread.php?p=753439

    My cruising website http://www.bluemagic.biz
  • SRLMSRLM Posts: 5,045
    edited 2009-01-21 04:00
    @Kye

    I used to wonder the same thing. Here's how I found out (and lots of other good stuff too...)

    http://forums.parallax.com/showthread.php?p=765086
Sign In or Register to comment.