@Reference inside of DAT block

CassLan · 2009-03-02 22:58

Hello,

I want to first thank the people who helped me out the other day with:
http://forums.parallax.com/showthread.php?p=788688

In continuing with this Menu function which is only provided the address of the start of that particular menus data, I have inside of the DAT Blocks the next Menu location to jump to:

At the moment the first piece of Info is the Title of the Menu, then the # of Choices, then the Label of Each Choice, then the StartingAddress of the Menu to jump too if that choice is selected:

DAT
MainMenu                byte "Main Menu      ",4
                        byte "System Info     ", long @SystemInfoMenu
                        byte "Setup Zones     ", long @MainMenu
                        byte "Setup Sensors   ", long @MainMenu
                        byte "Setup Outputs   ", long @SystemInfoMenu

SystemInfoMenu          byte "System Info    ",3
                        byte "Test Option 1   ", long @MainMenu
                        byte "Test Option 2   ", long @MainMenu
                        byte "Test Option 3   ", long @MainMenu

·The Problem is that if I write the hex memory address instead of the "@SystemInfoMenu" everything goes smoothly, however I'm finding (through printing variables on screen) that where the address of @MainMenu should be $0024, its showing up as $0014 when reading from the DAT block. Also when reading @SystemInfoMenu it should be reading $0084, its reading $0074.

Any idea why it would be the correct address -16 bytes?

Thanks,

Rick

Erik Friesen · 2009-03-02 23:08

Could it have something to do with the long boundary?

CassLan · 2009-03-02 23:27

Eric,
Erik,

If you are reffering to the Alignment of the bytes/longs, I have checked it against the Prop Manual's guidlines and Table 4-8: Example Data in Memory.
I will break it down as I am seeing it:

MainMenu                byte "Main Menu      ",4                            ---15 Bytes String Data + 1 Byte Dec  = 16Bytes (0-15)
                        byte "System Info     ", long @SystemInfoMenu       ---16 Bytes String Data + 1 Long Addr = 20Bytes (0-19)

It should all line up. If it didn't I dont think my program would·display the menu at all. (The alignment was an earlier problem which I resolved)

Post Edited (CassLan) : 3/3/2009 1:39:18 PM GMT

jazzed · 2009-03-02 23:44

All object data will be offset by $10 because that's where objects start ... the first $10 bytes are spin header bytes.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

CassLan · 2009-03-02 23:48

·

·

Steve, thank you again. Your absolutely correct. I can see that in the hex info (F8).

Rick

Timothy D. Swieter · 2009-03-03 08:49

CassLan - back around Christmas time I was working on something similar but got distracted with family and other items and haven't returned to the project I started. Your couple questions here kind of helped me to figure out the key problems I was running into.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com

heater · 2009-03-03 10:29

Quite a long thread formed when I asked about @ and @@ in DAT and elsewhere about a year ago. For sure cannot find it now.
Personally I feel that "@foo" should mean what it says wherever it is but at the time people almost convinced me the Spin way was sensible.

This program demonstrates the issue and the work arounds, as already suggested here:

CON
  _clkmode = xtal1 + pll8x
  _xinfreq = 10_000_000


OBJ

  TV       : "PC_Text"        'You can also use TV_Text or VGA_Text objects



VAR

  long foobar_addr
  
PUB start | object_base

  'Start the terminal
  TV.start(12)
  TV.str(string("at in dat test",13))

  TV.str(string("foobar = "))
  TV.hex(foobar, 4)
  TV.out(13)

  TV.str(string("foobar = "))
  TV.hex(long[noparse][[/noparse]@foobar], 4)            'WARNING This @ not same as in DAT
  TV.out(13)

  foobar_addr := @foobar              'WARNING This @ not same as in DAT
  TV.str(string("foobar = "))
  TV.hex(long[noparse][[/noparse]foobar_addr], 4)
  TV.out(13)

  foobar_addr := foobar_ptr           'FAILS because @ in DAT is wrong
  TV.str(string("foobar = "))
  TV.hex(long[noparse][[/noparse]foobar_addr], 4)
  TV.out(13)
  
  TV.str(string("foobar = "))         'FAILS because @ in DAT is wrong
  TV.hex(long[noparse][[/noparse]foobar_ptr], 4)
  TV.out(13)
  
  foobar_addr := foobar_ptr           'Fix it with $10
  TV.str(string("foobar = "))
  TV.hex(long[noparse][[/noparse]foobar_addr + $10], 4)
  TV.out(13)


  object_base := @@0
  foobar_addr := foobar_ptr           'Fix it with run time object base
  TV.str(string("foobar = "))
  TV.hex(long[noparse][[/noparse]foobar_addr + object_base], 4)
  TV.out(13)
  
  TV.str(string("foobar = "))
  TV.hex(long[noparse][[/noparse]foobar_ptr + object_base], 4)
  TV.out(13)

  repeat

DAT

foobar        long  3
foobar_ptr    long      @foobar       'WARNING This @ not same as in PUB

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

mojorizing · 2009-03-04 05:09

Why don't I see this address issue with the following code?· It displays the address and string at that address.......

'' Address issue?

CON
   
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000
 
  
OBJ
   
  Debug:    "FullDuplexSerialPlus"
  
   
VAR

PUB UpdateVariables 
 
     Debug.start(31, 30, 0, 57600)
     waitcnt(clkfreq*2 + cnt)
     Debug.tx(Debug#CLS)
         
     Debug.Str(String("mainmenu1 address"))   
     Debug.hex(@mainmenu1,2)
     Debug.Str(String(Debug#CR))
     
     Debug.Str(String("mainmenu2 address"))   
     Debug.hex(@mainmenu2,2)
     Debug.Str(String(Debug#CR))
     
     Debug.Str(@mainmenu1)
     Debug.Str(String(Debug#CR))
     
     Debug.Str(@mainmenu2)
     Debug.Str(String(Debug#CR))     
     
DAT

mainmenu1     BYTE "TESTTESTTEST        ",0
mainmenu2     BYTE "QWERTYQWERTY        ",0

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!

Post Edited (mojorizing) : 3/4/2009 5:17:08 AM GMT

CassLan · 2009-03-04 05:54

mojo,
The only time I experienced this issue was when the·Memory Reference·was located within the DAT section:

[size=2][code]
DAT
MainMenu                byte "Main Menu      ",4
                        byte "System Info     ", long @SystemInfoMenu
                        byte "Setup Zones     ", long @MainMenu
                        byte "Setup Sensors   ", long @MainMenu
                        byte "Setup Outputs   ", long @SystemInfoMenu

SystemInfoMenu          byte "System Info    ",3
                        byte "Test Option 1   ", long @MainMenu
                        byte "Test Option 2   ", long @MainMenu
                        byte "Test Option 3   ", long @MainMenu

[/code][/size]
I'm almost nervous to speculate because I know there are people who know a hell of a lot more than I do that read/respond regularly but I would have to guess that the Address references inside of the DAT blocks are calulated as an offset of the "usable" object memory, while the references inside of the code portion are calculated as an offset of the total memory, the difference being $10 bytes.

Try putting altering your code to something like this to see the result:
(I shortened one of the blank spaces off of each of your string values to align the Byte/Longs making the string·+ the terminating 0 = 20Bytes)

[size=2][code]
'' Address issue?

CON
   
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000
 
  
OBJ
   
  Debug:    "FullDuplexSerialPlus"
  
   
VAR

PUB UpdateVariables 
 
     Debug.start(31, 30, 0, 57600)
     waitcnt(clkfreq*2 + cnt)
     Debug.tx(Debug#CLS)
         
     Debug.Str(String("mainmenu1 address"))   
     Debug.hex(@mainmenu1,2)
     Debug.Str(String(Debug#CR))
     
     Debug.Str(String("mainmenu2 address"))   
     Debug.hex(@mainmenu2,2)
     Debug.Str(String(Debug#CR))

     Debug.Str(String("mainmenu2 address as referenced inside DAT block"))   
     Debug.hex(@mainmenu1[noparse][[/noparse]20],2)
     Debug.Str(String(Debug#CR))

     Debug.Str(@mainmenu1)
     Debug.Str(String(Debug#CR))
     
     Debug.Str(@mainmenu2)
     Debug.Str(String(Debug#CR))     
     
DAT

mainmenu1     BYTE "TESTTESTTEST       ",0, LONG @mainmenu2
mainmenu2     BYTE "QWERTYQWERTY       ",0

[/code][/size]

·Hope that answered what you meant.

Rick

·

mpark · 2009-03-04 08:04

Rick, you are basically correct. @symbol in a DAT section is computed at compile time. It is the offset from the start of the object to the symbol, not the absolute address of the symbol.

@symbol in a PUB or PRI method is computed at run time and is the absolute address of the symbol.

The top object ends up being placed in memory starting at $10, hence the 16-byte difference between the object-relative offset and the absolute address. But... sub-objects will end up starting at other addresses, so the offset for them won't be $10. That's when the @@ operator comes in. It simply adds the object's start address to whatever follows it, thereby converting object-relative offsets into absolute addresses.

heater · 2009-03-04 10:18

Except @@ does not work in DAT declarations, so you always end up having to "patch" up @ declarations with Spin code. Gack.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

mojorizing · 2009-03-04 21:19

Ok , I see what you mean, and reading page 278-279 in the manual·helps clarify things.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!

@Reference inside of DAT block

Comments