@ptrinc & @ptrdec bug in 28X2

[BeanieBots]

PE V5.2.9
Firmware B.0 & B.1

Neither @ptrinc nor @ptrdec behave as expected in the simulator.
@ptrinc seems OK on the 28X2 but @ptrdec does not.

example for @ptrinc:

do
  b0=@ptrinc
  sertxd(#ptr,CR,LF)
  pause 200
loop

In simulation, the output goes up to 255 OK but then stays at 255.
I was expecting it to go to 1023 and then roll-over.
When programmed into a chip it behaves as expected.

example for @ptrdec:

do
  b0=@ptrdec
  sertxd(#ptr,CR,LF)
  pause 200
loop

In simulation, it decrements to 0 from any initial starting value of ptr but stops at zero. I was expecting it to roll-under back to 1023 and continue to count down.
When programmed into a chip (tried B.0 & B.1) it returns a 'strange' number set with no obvious pattern.

Replacing "b0=@ptrdec" with "b0=@ptr:dec ptr" gives the expected result from the chip but still does not work in the simulator.
In the simulator if ptr starts of at zero, simulation decrements to the expected value of 255 but no further decrements take place after that.

EDIT:
In simulation, replacing "b0=@ptrinc" with "b0=ptr:inc ptr" gives a rollover but it occurs at 255 instead of the expected 1023.

 

[Technical]

Thanks, we will look into it.

 

[BCJKiwi]

@ptrinc pointing to wrong address

Picaxe 28x2 B.0 @ setfreq m8 and setfreq em40
PE 5.3.1

If b8 => @ptrinc then 'Leds 2 thru 8
get Led2_8 ,b18
ElseIf b8 => @ptrinc then 'Leds 2 thru 7
get Led2_7 ,b18
ElseIf b8 => @ptrinc then 'Leds 2 thru 6
get Led2_6 ,b18
ElseIf b8 => @ptrinc then 'Leds 2 thru 5
get Led2_5 ,b18
ElseIf b8 => @ptrinc then 'Leds 2 thru 4
get Led2_4 ,b18
ElseIf b8 => @ptrinc then 'Leds 2 thru 3
get Led2_3 ,b18
ElseIf b8 => @ptrinc then 'Led 2
get Led_2 ,b18
EndIf

Simulator works OK
Chip returns incorrect ptr address.

changed code to @ptr and ptr=ptr+1 as follows;

If b8 => @ptr then
get Led2_8 ,b18
goto Display
EndIf
ptr = ptr + 1
If b8 => @ptr then
get Led2_7 ,b18
goto Display
EndIf
ptr = ptr + 1
If b8 => @ptr then
get Led2_6 ,b18
goto Display
EndIf
ptr = ptr + 1
If b8 => @ptr then
get Led2_5 ,b18
goto Display
EndIf
ptr = ptr + 1
If b8 => @ptr then
get Led2_4 ,b18
goto Display
EndIf
ptr = ptr + 1
If b8 => @ptr then
get Led2_3 ,b18
goto Display
EndIf
ptr = ptr + 1
If b8 => @ptr then
get Led_2 ,b18
EndIf

and it works OK in simulator and on chip.

Any suggestions?

 

[Technical]

@ptrinc can not be used reliably like this due to the way elseif is processed, the compiler should probably block this structure, which is not something we ever considered being done!

 

[hippy]

I'm a bit confused over post #3 as the two code equivalents don't seem to match to me ...

If b8 => @ptrinc then
get Led2_8 ,b18
ElseIf ...

If b8 => @ptr then
get Led2_8 ,b18
goto Display
EndIf
ptr = ptr + 1
If ...

With @ptrInc being an indivisble operation, I'd have expected the second @ptr alternative code to achieve exactly the same to be ...

If b8 => @ptr then
ptr = ptr + 1
get Led2_8 ,b18
goto Display
EndIf
ptr = ptr + 1
If ...

 

[BCJKiwi]

@ Technical
Thanks,
A block would be helpful as hours were spent trying to debug this issue! Particularly difficult when sertxd couldn't be used - had to slow the chip to 8MHz to check it.
Had started the project on a 28X1 which also exhibited strange but slightly different behaviour in the same area. May go back to the 28X1 and see if it behaves with the same changed code.

@Hippy
With the original construct, at the end of the sequence the code falls through to the "Display:" routine.
With the revised construct, each test is completely separate so the goto has to be used to jump over any remaining tests in the sequence.
I guess the true equivalent is as you suggest but since the code only passes once through this sequence per program cycle, there is no need to place the ptr=ptr+1 any earlier than actually required. If the test is met, code exits the sequence and the next ptr=ptr+1 is not required.