pointer to DAT as DAT

PaulForgey

EDIT: late night stupidity. I was assuming wrong about DAT locations vs objects, as there is still an object offset. I was pointed to the _operator_ section of the docs which explains this (not the DAT section).

I wish to have addresses of other DAT locations as DAT constants. Because this section is not relocated (it isn't object data), all this is known at compile time and should be fine. So if I try something like:

DAT
label
LONG $1234567

pointer
LONG @label ' or WORD to be compact, as pointers never exceed 16 bits

This actually does not work as expected. In the specific case of my test program, @label is $3c, and LONG[@label] is $1234567 as expected. But pointer[0] is $4c, not $3c. Why is this? Is what I am trying to do possible? If not, why not?

Heater.

@ does not work as expected in DAT blocks like that.

The BST Propeller IDE added a "@@@" operator to do what you want.

DAT
label
LONG $1234567

pointer
LONG @@@label ' or WORD to be compact, as pointers never exceed 16 bits

I think this is now supported in OpenSpin hence in the Propeller IDE.

Sadly not in the Parallax Propeller Tool.

ErNa

obviously the @ operator determines the address at compile time. The code then is loaded with an offset of 16 bytes. This offset is obviously fixed, so I in an init routine adjust all pointers by 16, and do not use the @@ or @@@ operator

Electrodude

The 16 byte offset only applies to the top object, which is always placed at offset 16. For child objects, which come after the top object, the offset will be higher, so you have to use @@ or @@@ for child objects.

JonnyMac

If you're using Propeller Tool you can use @@ at run time to deal with the object offset. Here's a simple example:

dat

  DSun          byte    "Sunday", 0
  DMon          byte    "Monday", 0
  DTue          byte    "Tuesday", 0
  DWed          byte    "Wednesday", 0
  DThu          byte    "Thursday", 0
  DFri          byte    "Friday", 0
  DSat          byte    "Saturday", 0

  Day           word    @DSun, @DMon, @DTue, @DWed, @DThu, @DFri, @DSat

To print a day name to the terminal you might do this:

  term.str(@@Day[idx])

Heater.

JonnyMac,

Wow, thank you.

I have been wondering for years what possible use @@ is!

It does not help if you are writing in PASM though.

tonyp12

@@ indirect addressing of an address, very useful especially with lookup-table that have random lengths.

day[] contains the memory locations of 7 zero-terminated ascii strings.

@@ you are telling term.str to start sending bytes from the address stored in a array[] of addresses.

Heater.

Oddly, I have never done that.

Ariba

JonnyMac wrote: »

If you're using Propeller Tool you can use @@ at run time to deal with the object offset. Here's a simple example:

dat

  DSun          byte    "Sunday", 0
  DMon          byte    "Monday", 0
  DTue          byte    "Tuesday", 0
  DWed          byte    "Wednesday", 0
  DThu          byte    "Thursday", 0
  DFri          byte    "Friday", 0
  DSat          byte    "Saturday", 0

  Day           word    @DSun, @DMon, @DTue, @DWed, @DThu, @DFri, @DSat

To print a day name to the terminal you might do this:

  term.str(@@Day[idx])

An alternative is to adjust the offsets programmatically in the Spin start-methode:

PUB Main : i | offset

  offset := @DSun - Day[0]      'adjust @-offset in Dat:
  repeat i from 0 to 6
    Day[i] += offset

Then you can access the array without @@:

term.str(Day[idx])

and the pointers are also correct for assembly code.

With the way I have done the offset adjust, it works also if you call the startmethode more than once. For example when a Reset occures.

Andy

PaulForgey

Yes, I am using this for lookup table into variable length constant data. I actually did not know about the @@@ operator, so thank you for pointing that one out! I'll have to see if it's supported in the version of OpenSPIN I am running (macOS Sierra, so I'm limited to OpenSPIN <= 1.00.78). It's a bit more elegant than using

@@(WORD[@SomePointers][Index])

at runtime.

This code actually needs to be able to run in multiple cores, so adjusting the values at runtime isn't a good option for me, but that's a good trick to know.