Shop OBEX P1 Docs P2 Docs Learn Events
Did this DAT get defined as bytes ? ? — Parallax Forums

Did this DAT get defined as bytes ? ?

Don PomplunDon Pomplun Posts: 116
edited 2011-07-17 22:27 in Propeller 1
Here was a hair puller! chkForCmd is supposed to cycle thru the cmdTable in the DAT block looking for a match. Worked in my old monolithic code, as in #2 below. In my new code I thought I had the same thing in #1 and added a comment so I could understand it in the future. But I was getting twice as many scans as I expected, and never got matches. When I put the label on the same line as the first definition, everything got fixed.
My guess is that by not defining data on the label line,it treated the whole thing as bytes. Correct?, or something more subtle/else?
TIA
Don

PRI chkForCmd( cmd ) | i
  i := 0
  repeat
    
    if cmd == cmdTable[i]
      return cmdTable[i+1]
    i+=2
  until cmdTable[i] == 0  ' end of table
  return 0  '  means command not found  

      
DAT  '  #1

'  This table doesn't work right
cmdTable  ' format is cmd number, and number of pounds
              word 1, 2    ' OFF cmd, requires 2  #'s
              word 3, 2    ' ON  cmd, requires 2  #'s
              word 0,0     ' ***********   ALWAYS LAST IN LIST so loop can detect the end




DAT  '  #2

'  putting the label on the first data line fixes the problem
        ' format is cmd number, and number of pounds
cmdTable      word 1, 2    ' OFF cmd, requires 2  #'s
                   word 3, 2    ' ON  cmd, requires 2  #'s
                   word 0,0     ' ***********   ALWAYS LAST IN LIST so loop can detect the end

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2011-07-13 20:45
    In your first example cmdTable picks up the alignment from the previous DAT section. If that ended on e.g. 2n+1 it's effectively off by one (for table use). Meaning if your cmdTable were in the first DAT section of your object you wouldn't see a difference between the two.
  • Don PomplunDon Pomplun Posts: 116
    edited 2011-07-14 08:41
    Well, there is only one of those DAT blocks. But it sounds ike you're agreeing that the blank spec in DAT #1 implicitly sets aside a byte.
  • KyeKye Posts: 2,200
    edited 2011-07-14 12:14
    Read up about word and long alignment in the propeller manual. There's a fix for this in SPIN.
  • RaymanRayman Posts: 14,876
    edited 2011-07-14 13:04
    I think in the #1 case, cmdTable is assumed to be a byte by default.
    So, your reference cmdTable is just retrieving bytes, not words.

    You could have just specified cmdTable to be a word like this:

    cmdTable word 'this is a word table
  • Don PomplunDon Pomplun Posts: 116
    edited 2011-07-14 13:32
    OK, I read the DAT section of the manual again. Apparently if you specify a Symbol (like I did) by itself, it implies Byte, and that's what messed up the rest of the table.
    Kye mentioned "a fix in Spin" -- a reference, please.
    Interestingly, in the DAT section (p.208) it seems to say in:
    <Symbol> Alignment <Size> <Data> that you could have a line like:
    table byte word 12345 that would define "table" as byte aligned words. Is this a misprint, since I see no examples specifying both alignment & size?
  • localrogerlocalroger Posts: 3,452
    edited 2011-07-14 15:58
    When you specify a symbol it points at the address of the current line. If the line is blank, that is the next byte address beyond the last one used, but if it's a word or long the compiler skips bytes if necessary to align the data before it assigns the symbol to the address of that line. So with words you have a 50% chance of it working if you put the symbol on the line before.

    You can also do stuff like this:

    mytable byte word $1001, $2002, $3003

    That will create words that aren't necessarily aligned, which can be useful if they are mixed in with bytes (such as a lookup table of keywords with embedded pointers).
  • kuronekokuroneko Posts: 3,623
    edited 2011-07-14 16:21
    Well, there is only one of those DAT blocks. But it sounds ike you're agreeing that the blank spec in DAT #1 implicitly sets aside a byte.
    Yes, the default is byte and I temporarily forgot - as Rayman mentioned - that the references get messed up in this case. Which means that cmdTable[0] and cmdTable[1] are treated as byte array elements. Apologies for the confusion. Addresses will be the same in this case (provided there is no previous DAT interference), interpretation changes.
  • Don PomplunDon Pomplun Posts: 116
    edited 2011-07-17 12:59
    Thanx for all the pointers (pun intended ;=)
    Now if I can remember the Lessons Learned next time the issue comes up.

    I still tend to use PICs because it's hard to find projects worthy of 8 processors. Aand, of course a PIC is only a couple bucks.
    Don
  • AleAle Posts: 2,363
    edited 2011-07-17 22:27
    That's why the listing is a good idea. You can always realign using a long, or org.
Sign In or Register to comment.