Shop OBEX P1 Docs P2 Docs Learn Events
long[@buffer+howmany?] — Parallax Forums

long[@buffer+howmany?]

Erik FriesenErik Friesen Posts: 1,071
edited 2008-08-04 20:32 in Propeller 1
I'm having a problem program moment.· Using long[noparse][[/noparse]@buffer+x] does x=one byte address, or four.

Comments

  • TimmooreTimmoore Posts: 1,031
    edited 2008-08-01 21:16
    its in bytes
  • jazzedjazzed Posts: 11,803
    edited 2008-08-01 21:44
    Yup. The first 90% of spin is easy; this is part of the last 10%.
    The "type cast" is only for the data, not the address.

    It seems that these two are equivalent though:
    ·
    long[noparse][[/noparse]@buffer+4] == long[noparse][[/noparse]@buffer][noparse][[/noparse]1]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-08-01 21:46
    It's in bytes, but you have to make sure the resultant address is on a long boundary. As an alternative, you can use long[noparse][[/noparse]@buffer][noparse][[/noparse]x], where x is in longs.

    -Phil

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    'Still some PropSTICK Kit bare PCBs left!
  • VIRANDVIRAND Posts: 656
    edited 2008-08-03 07:34
    long[noparse][[/noparse]@buffer+4] == long[noparse][[/noparse]@buffer][noparse][[/noparse]l]

    Often it seems to me as if my programs will only work with one form or the other, without a clue for which or why,
    especially with the byte[noparse][[/noparse] ] function, for example: byte[noparse][[/noparse]x+i]<>byte[noparse][[/noparse]x][noparse][[/noparse] i ].
    Maybe I'm blind to a typo every time, but whenever it doesn't work, changing it does fix it.
    I specifically remember the second program I wrote with byte[noparse][[/noparse] ] didn't work so I checked the manual,
    and learned the second form, used it, and it worked.

    Post Edited (VIRAND) : 8/3/2008 7:41:32 AM GMT
  • hippyhippy Posts: 1,981
    edited 2008-08-03 19:40
    byte[noparse][[/noparse]x+i]<>byte[noparse][[/noparse]x][noparse][[/noparse] i ]

    Is that correct, they're not synonymous ? I would have thought they were but cannot try it at present.
  • jazzedjazzed Posts: 11,803
    edited 2008-08-04 00:34
    I always use byte[noparse][[/noparse]x+i] for strings with no issues.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • RossHRossH Posts: 5,505
    edited 2008-08-04 01:23
    I've noticed the same thing - the "size[noparse][[/noparse]x+i]" and "size[noparse][[/noparse]x][noparse][[/noparse] i ]" forms do not seem to give the same results, although I think the documentation says they should (I'm at work and can't check at the moment). This may be a SPIN compiler bug.

    I generally now use the [noparse][[/noparse]x+i] format.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-08-04 06:04
    I'm not sure what's causing these problems, but I'm convinced it's nothing in the compiler. Try this program:

    [b]CON[/b]

  [b]_clkmode[/b]      = [b]xtal[/b]1 + [b]pll[/b]16x
  [b]_xinfreq[/b]      = 5_000_000

[b]VAR[/b]

  [b]byte[/b]  bytes[noparse][[/noparse]16&#093;
  [b]long[/b]  seed

[b]OBJ[/b]

  pr : "tv_wtext"

[b]PUB[/b] Start | i

  pr.start(12)
  seed := [b]cnt[/b]
  [b]repeat[/b] i [b]from[/b] 0 to 15
    bytes[noparse][[/noparse]i&#093; := ?seed
  [b]repeat[/b] i [b]from[/b] 0 to 15
    pr.hex(bytes[noparse][[/noparse]i&#093;, 2)
    pr.out(" ")
    pr.hex([b]byte[/b][noparse][[/noparse]@bytes + i&#093;, 2)
    pr.out(" ")
    pr.hex([b]byte[/b][noparse][[/noparse]@bytes&#093;[noparse][[/noparse]i&#093;, 2)
    pr.out(13)


    When I run it, I get identical values across each line.

    -Phil

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    'Still some PropSTICK Kit bare PCBs left!
  • VIRANDVIRAND Posts: 656
    edited 2008-08-04 07:34
    I really think that when I play with that program it will soon mysteriously stop working,but I hope I just make a fool of myself.
  • RossHRossH Posts: 5,505
    edited 2008-08-04 10:22
    Yes, this program works in all size variations (i.e. byte, word & long). I cannot currently locate any code that fails, but (like Virand) I have a strong suspicion it sometimes does. Also like Virand, whenever I find a case I just change it to one of the other modes and move on.

    Next time I find an example I will preserve it and post it.
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2008-08-04 11:27
    Maybe (repeat until X==1 and X==5) falls into the same category? It seems to only recognize the first condition sometimes.
  • BradCBradC Posts: 2,601
    edited 2008-08-04 11:43
    Looking at the bytecode the compiler generates they are not the same
    Long[noparse][[/noparse]@A+1] gets the address for A and adds one to it. As it's reading a long it will chop off the bottom 2 bits as it reads it.
Long[noparse][[/noparse]@A][noparse][[/noparse].1] gets the address for A, Pops 1 on the stack as an index and calls to read.
Long[noparse][[/noparse]@X][noparse][[/noparse].1] should return X. Long[noparse][[/noparse]@X][noparse][[/noparse].2] should return X+4
Long[noparse][[/noparse]@X+1] should effectively return X .. as should Long[noparse][[/noparse]@X+2]..


    For Byte, they should be equivalent.. words will of course only lop off the lowest bit.

    Ignore the dots in the parens.. stupid forum software destroys the formatting even if its in a code block..

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • hippyhippy Posts: 1,981
    edited 2008-08-04 13:12
    Erik Friesen said...
    Maybe (repeat until X==1 and X==5) falls into the same category? It seems to only recognize the first condition sometimes.

    I couldn't see anything wrong with the bytecode generated there. Note that the two conditionals can never both be true so it's an infinite loop; maybe there's some other problem you are seeing ?

    ====                                  ; PUB Main | x
====                                  ;   repeat until x==1 and x==5
====                                  ;     x++

                                      ALIGN    STACK

       +0000                          LONG     0
       +0004                 VL1:     LONG     0

                                      ALIGN    SPIN

0018         64              S2:      PUSH     VL1.LONG
0019         36                       PUSH     #1
001A         FC                       EQ
001B         64                       PUSH     VL1.LONG
001C         38 05                    PUSH     #5
001E         FC                       EQ
001F         F0                       LOG_AND
0020         0B 04                    JPT      T3
0022         66 2E                    USING    VL1.LONG INC
0024         04 72                    GOTO     S2
0026         32              T3:      RETURN



    For "long[noparse][[/noparse]x][noparse][[/noparse]y]' and "long[noparse][[/noparse]x+y*4]", the compiler generates different bytecode but the functionality appears to be the same for long, word and byte.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-08-04 15:40
    My suspicion is that those programs which fail are using expressions of the form byte[noparse][[/noparse]x + i] rather than the form byte[noparse][[/noparse]@v + i]. In the former, if the variable x, which contains the base address, gets changed somehow, things will get messed up. In the latter, @v can never change, resulting in fewer chances for a programming bug to enter the picture.

    -Phil

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    'Still some PropSTICK Kit bare PCBs left!
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2008-08-04 16:57
    I actually think it was a repeat while. You know how it goes something doesn't work so you change it and move on and don't take the time to document it.
  • jazzedjazzed Posts: 11,803
    edited 2008-08-04 17:37
    BradC said...
    Long[noparse][[/noparse]@A+1] gets the address for A and adds one to it. As it's reading a long it will chop off the bottom 2 bits as it reads it.
Long[noparse][[/noparse]@A][noparse][[/noparse].1] gets the address for A, Pops 1 on the stack as an index and calls to read.
Long[noparse][[/noparse]@X][noparse][[/noparse].1] should return X. Long[noparse][[/noparse]@X][noparse][[/noparse].2] should return X+4
Long[noparse][[/noparse]@X+1] should effectively return X .. as should Long[noparse][[/noparse]@X+2]..


    Your third line is inconsistent with experience. It should read:

    Long[noparse][[/noparse]@X][noparse][[/noparse]0] should return X. Long[noparse][[/noparse]@X][noparse][[/noparse]1] should return Long[noparse][[/noparse]@X+4].


    Erik, if you don't mind the suggestion, a root cause analysis can go a long way to keeping problems like you mention from coming back.



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • BradCBradC Posts: 2,601
    edited 2008-08-04 19:13
    Ta for the correction. I was pulling it out of my nether regions based on playing with Spin bytecode directly. I'd not tested it

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • VIRANDVIRAND Posts: 656
    edited 2008-08-04 20:32
    PhiPi said...
    My suspicion is that those programs which fail are using expressions of the form byte[noparse][[/noparse]x + i] rather than the form byte[noparse][[/noparse]@v + i]. In the former, if the variable x, which contains the base address, gets changed somehow, things will get messed up. In the latter, @v can never change, resulting in fewer chances for a programming bug to enter the picture.

    I would agree with that hypothesis. I clearly remember replacing byte[noparse][[/noparse]x] with byte[noparse][[/noparse]x][noparse][[/noparse]0] to get something working.
    I'll look for that program.
Sign In or Register to comment.