@@@

Comments

• mojorizing Posts: 249

  2012-07-26 22:02 edited 2012-07-26 22:02

  Can't recall a @@@ post, but I was involved in a post with "@ in a DAT" with a mention (post #7) of @ and @@ .... and spin code called "foobar".......
  
  
  http://forums.parallax.com/showthread.php?110875-Reference-inside-of-DAT-block&highlight=foobar
• Peter Jakacki Posts: 10,193

  2012-07-26 22:21 edited 2012-07-26 22:21

  This is in the BST manual although I have never bothering reading before I had to go search for it.
  
  From the BST manual then:
  5.2
  @@@ - The absolute address operator
  In SPIN methods, there are the @ & @@ operators. In PASM you have @. In all contexts they mean
  different things.
  In SPIN, @ means “Give me the HUB address of that variable”. The interpreter does this at runtime as it only
  knows the absolute address when it know where it is in the Propeller. This applies to global (VAR), Local
  (PUB/PRI) and PASM (DAT) variables. The @ always returns the address of that variable in the HUB.
  In SPIN, @@ means give me the compile-time offset (It's only used when referencing variables in a DAT
  block) plus the object base address (this results in the correct absolute HUB address). Again, its a runtime
  operator only.
  
  In PASM, @ means “Give me the offset of this symbol into the DAT section”. It is a relative value with its
  base as the start of the objects DAT block.
  The @@@ operator results in a compile-time constant that gives the absolute hub address of the symbol in
  question. It's a special use symbol and it's not widely used. If you know you need it, you know what it is.
  Warning : The Propeller Tool will compile the @@@ operator as valid code in a SPIN method, however it will
  give a result far from what you want it to do!
• User Name Posts: 1,451

  2012-07-26 22:38 edited 2012-07-26 22:38

  @mojorizing : Might have been that thread, or the one Heater was referring to. Memories get mixed up over time...I can't be sure it involved @@@.
  
  @PeterJakacki: Thanks for the great clarifications. As fate would have it, it is your modification of HS-SerialRx (which I was trying to compile with PropTool) that led to the OP. Perhaps the simplest solution is just to use BST, although I'd imagine that there is some established way to return the HUB address of a specified symbol in PropTool.
• Peter Jakacki Posts: 10,193

  2012-07-26 23:10 edited 2012-07-26 23:10

  I like using BST for many reasons but primarily I think it's because it provides a compiler listing so I can see how it is handling the compiling and where it is putting it. This proves invaluable when trying to get everything right when you go beyond straightforward Spin or PASM coding.
  

  1BA0(0046) 8B 1A 00 00 | rxwr                    long    @@@HSSerialRx+3    ' byte address of rxwr in hub
  1BA4(0047) 8C 1A 00 00 | rxbuf                   long    @@@HSSerialRx+4    'pointer to rxbuf in hub memory
  

  
  I don't know of an equivalent that works across objects in the Spin tool. The normal @symbol+$10 works fine as long as it's not an included object.