Help with table access

max72 · 2010-07-07 14:43

I have the followiing code:
I cannot undestand whi I can access the second table with no problems, while the first table can only be accessed using the long method. They look the same, but the do not behave the same way. Could you please help me?

Massimo

VAR     ''Setup Variables for this demo
long    A_lat,A_long
long    B_lat,B_long



PUB Main | tmp  ,i

    pst.start(9600)



    repeat
       pst.char(0)
       pst.str(string("1->2:"))
       A_lat:=long[noparse][[/noparse]@punti_lat]
       B_lat:=punti_lat
       A_long:=punti_long
       B_long:=punti_long
       pst.char(13)
       

       scrivi_pst
       waitcnt(cnt+clkfreq)

      


PUB  scrivi_pst
     pst.str(string("Lat_A "))
     pst.dec(A_lat)
     pst.char(13)
     pst.str(string("Lat_B "))
     pst.dec(B_lat)
     pst.char(13)
     pst.str(string("Long_A "))
     pst.dec(A_long)
     pst.char(13)
     pst.str(string("Long_B "))
     pst.dec(B_long)
     
     

dat

punti_lat
long   0
long   271010000
long   271009167
long   271008333
long   271008750
long   271010333
long   271010167



punti_long
long   0
long   61001667
long   61005000
long   61003333
long   61001833
long   61002917
long   61004833

Mike Green · 2010-07-07 14:59

You need to have "long" after the label like: punti_long long

The compiler uses the "long" to tell it what size array element to use and how it's aligned..

max72 · 2010-07-07 15:13

Ok, but why it works with punti_long and not with punti_lat?
I guessed the alignement can be on the next line.
Is the compiler aligning the second table because I have a former with long declared?

Massimo

max72 · 2010-07-07 15:17

It works, I simply changed the line as you suggested..
If the table comes from a spreadsheet to have it aligned will require a little bit of regexp stuff..
Thanks.

dat


punti_lat  long   0
           long   271010000
           long   271009167
           long   271008333
           long   271008750
           long   271010333
           long   271010167




punti_long long   0
           long   61001667
           long   61005000
           long   61003333
           long   61001833
           long   61002917
           long   61004833

Post Edited (max72) : 7/7/2010 3:35:22 PM GMT

potatohead · 2010-07-07 16:55

You could just start the list with the label as well. Move punti_long down to the first line that actually has a value, eliminating the "long 0"

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

max72 · 2010-07-07 17:29

I started with a dummy table entry (my long 0 ) simply because I was making a fast test, and the index was running from 1, while table indexing starts from 0.
I was just lazy...

Massimo

Mike Green · 2010-07-07 18:51

Leave off the "0" on the dummy table line. You need the "long" to tell the compiler how the label is to be treated. If there's no "0", there's no storage allocated.

I think what's happening is that the "DAT begins a section that could be aligned in any way (bytes, words, or longs). The label "punti_lat" has no alignment information associated with it and causes an error while the label "punti_long" follows a "long" directive that establishes long alignment at that point. I don't think this is a good way to do things, but it's easily fixed by always starting a table like this with byte, word, or long and no operands like "punti_lat long".

max72 · 2010-07-07 19:02

Thanks.
I misunderstood the alignement point.
It's amazing how a couple of code lines written down to test another function can bring problems and better understanding...

Massimo

Help with table access

Comments