Obtaining current assmbler Address

rpraver

Based on a response from Peter, I want to start a new thread.
Given the Following:

DAT
        ORG
_ENTRY  ...
        ...
:LABEL  WORD #:LABEL+2
:HERE   

How would one go about accomplishing the effect of getting the address of the lable + 2
which would be effectively the starting address of :HERE

CJ

hub location or cog location?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

deSilva

And what is the rational of your question? Why did you use # ?
Just press F8 and you have all your answers..

DAT
_ENTRY  nop
        long $ffffffff
:LABEL  WORD :LABEL+2
:HERE   long $eeeeeeee 

deSilva

BTW: "#" is nothing but an indicator that the immediate bit be set in an instruction.

If you are after "HUB"- addresses - as CJ was asking - the situation is more complex (and may be confusing)

DAT
org 0
_ENTRY  nop
        long $ffffffff
LABEL  word@LABEL+2
:HERE   long $eeeeeeee 

(a) you cannot use "locally scoped" names, thus I had to remove the ":"

(b) In contrast to the example in my previous posting, where the contents of :LABEL had been "4" (as :LABEL is Cell 2, and 2+2 = 4), the contents of LABEL in this example depends on whether there are other DAT section before this specific DAT section. ORGs are of no significance to this.

Looking at the memory map shows "12" hex which is a little bit confusing, as we might have expected to see "24" hex, as this is the HUB-address of :HERE according to the memory dump (Note again that the value "4" in the COG-memory example has also no relation to :HERE!)

The reason is, that HUB-addresses (@) of DAT memory cells are stored in relation to the "compile unit" (i.e. the "object") start address only. You will still find this value "12" when you embed your code within lots of other objects and far down in memory.

Utilizing @-presets of DAT memory needs the SPIN @@-operator; AFAIK there is no equivalent construct to find the needed object offset from an assembly program...

(c) It is syntactically (!) not possible to use an address of VAR memory in an @-preset.
The rational behind this is, that there can be multiple instantiations of objects, each having its own set of DAT-memory, so "@someVAR" makes no sense in the first place (or for "singletons" only, but this is not a SPIN concept..). The DAT area however is as unique as the code area.

Hope this explanation helped, as although everything is quite straightforward, there can be some confusion in the beginning

Post Edited (deSilva) : 7/28/2007 7:33:39 AM GMT