Explanation Please

rpraver

Based on the following code snipit can someone explain
why I had to use the LAB2 line to correctly store the address,
where as the LAB1 line is off by 16 bytes
Does it have to do with the 16 byte initializtion I see when I compile.
if so please explain why LAB1 does not work.
Should not the compiler produce the correct value for the LAB1 line
automatically?

DAT
   LAB1    word @LAB1
   LAB2    word @LAB2 + $10

CardboardGuru

Look in the stickies at the beginning of the forum for "Propeller Tricks and Traps", and you'll see it explained on page 9 of the PDF.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com

deSilva

@Rpraver: I tried to explain it THOROUGLY in your last thread! I failed :-(
Please, please understand that @XXX in the DAT section are neither HUB nor COG adresses, but numbers to be used with the @@ operator.

Mike Green

It's a little complicated ...

When the compiler compiles an object, it doesn't know where the object goes yet. All the addresses are relative to the start of the object's hub memory. A later phase of the compiler shuffles everything around, combines multiple copies of the code and DAT areas. When the Spin @ operator executes, the relative address is made into an absolute address. That can't be done for constant @ operators in DAT constants like what you show. As a result, there's the @@ operator which adds the address of the start of the object at run-time. Note that this only affects Spin code.

In assembly code, there are two issues ...

1) The cog is long word addressable rather than byte addressable, so none of these constant byte addresses are valid

2) The assembly code is copied into the cog before execution and you can have more than one cog program in a Spin object. The assembler/compiler keeps two separate program counters, one is in bytes (for Spin use) and the other is in long words (for assembly use). When labels are used in assembly instructions, the assembly program counter is used. When labels are used in Spin, the Spin program counter is used. In constants, since they're intended mostly for use for tables in Spin, the Spin program counter is used.

Maybe there ought to be some variant of the LONG statement that forces the use of the cog program counter in expressions.

deSilva

Mike Green said...
Maybe there ought to be some variant of the LONG statement that forces the use of the cog program counter in expressions.

There is no urgent need for it, as

label LONG label

is valid assembly code that also honours the ORGs. It must in fact, as the numerical value of "label" has to be known from the beginning...

Mike Green

Yes, "label LONG @label" would provide the Spin object relative byte address while "label LONG label" would provide the assembly long word address.

CardboardGuru

To clarify. In these statements

DAT
ORG 5
NOP
LABEL LONG LABEL

The compiler stores LABEL in the symbol table with a value of the number of bytes from the start of the object in which these statements occur.

Then, where LABEL is used as the expression of the LONG statement, the compiler uses the value (LABEL - START_OF_OBJECT)/4 + CURRENT_COG_ADDRESS.

So in this example, LABEL LONG LABEL compiles as the long value 6. (ORG 5 gives you 5, plus 1 for the NOP instruction)

Whereas LABEL LONG @LABEL would compile as the value in bytes of the offset of this statement from the start of the object.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com

Post Edited (CardboardGuru) : 7/29/2007 4:06:24 PM GMT

Fred Hawkins

These threads (and there are many) should ring alarm bells with Parallax. Your manual is not up to this task, partly because you have aimed a bit too high. A nice chart of these various reference problems would go far to alleviate the confusion. (Hint)

rpraver

Some of you seem to generally helpful other seemed bothered to answer. I am approximatly
3.5 to 3 wks into this environment.
I am only asking answers to observations that I have experienced.

Everytime I compile I have noticed that the DAT section reguardless of the location in the source
is always at the head of the output, it is always $10 (16 bytes offset from $0000. I just was wonder the meaning.
there my workarounfd was stating nothing more then

LABEL WORD @LABEL + $10

Works fine thats all.

Paul Baker

Yes,

LABEL WORD @LABEL

then execute WORD[noparse][[/noparse]@LABEL] += $10 before using it, or you could compute the entire value at runtime.

What you are observing is that the header of every program is 16 bytes in length, but programing the Propeller in the manner in which it was intended to be programmed, you should never have to account for this header in your calculations. What you observe is only true when compiling a single object. Once you have more than one you cannot count on the 16 byte relation between the object offset and memory location.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 7/30/2007 2:43:03 AM GMT

deSilva

rpraver said...
Some of you seem to generally helpful other seemed bothered to answer.

Praver, I answered ALL your questions some days ago in your other thread; sorry, that I must have got the impression, you were not really listening....

deSilva some days ago said...

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