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.
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.
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.
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.
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..
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.
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 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.
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.
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.
Comments
The "type cast" is only for the data, not the address.
It seems that these two are equivalent though:
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
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
Is that correct, they're not synonymous ? I would have thought they were but cannot try it at present.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I generally now use the [noparse][[/noparse]x+i] format.
When I run it, I get identical values across each line.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Next time I find an example I will preserve it and post it.
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!
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 ?
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Your third line is inconsistent with experience. It should read:
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
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.