use of the goto @n statement

[garysdickinson]

Gentlemen,

I am quite confused about the goto statement. I have never used one as it is considered by many to be "unsophisticated".  But I have been playing with them in an attempt to write a CF that consumes a lot of CPU time without the use of for/next, while/endwhile, delay or SetLCD statements as all of these resets the WDT mechanism.

So I set out to write a non-sense program that used nested for/next loops and a lot of string functions. I picked on the string functions because they are slow.

I wrote the following nonsense code and cannot get it to compile:

' for_next
'
' This code is an eumulation of a for/next loop using goto statements
'
'
/*
   for j = 1 to 3
      b = b + b
   next
*/


j = 1         ' loop counter initialization
@200
if j > 3      ' range check
   goto @220
else
   ' loop body
   '
   b = b + b
@210   ' continue entry point
   j = j + 1   ' counter + step value
   goto @200
endif
@220         ' loop exit
[/color]

The compiler exits with the following error message:

Error:Undefined GOTO destination: @: "-36"

and the first 3 characters of the last line of the program are highlighted in yellow:

@220         ' loop exit

Any idea what this error message means?

Any idea what I have done to offend the compiler?

Best regards,

Gary D*ckinson

[garysdickinson]

I think I know what the problem with the program. The TBASIC parser does not handle the "n" part of the goto @n correctly.

The online documentation for GOTO:

To branch unconditionally out of the normal program sequence to a specified line with label @n within the present Custom Function. The destination line must have a corresponding line label marked as "@n", where n must be a constant within 0-255. Note that the label is local only to the present CusFn. i.e. another CusFn may have a label with the same n but the GOTO @n will only branch to the line label within the same CusFn.


Is not correct. The range 0-255 is that of an unsigned 8-bit integer.  The TBASIC parser accepts "n" in the rage of 0-255 decimal as well as &h00 to &Hff as an 8-bit value but subsequently sign-extends it to a 16 or 32-bit variable.  

The error message gives it away.  The "-36" as an 8-bit signed value is 0xDC. If 0xdc is treated as an unsigned 8-bit variable then it would be 220 decimal.  The code has "@220" as a target of a goto but the parser can't find the target if it is between 128 and 255.
 
You might consider correcting the documentation for goto @n to indicate that the only usable values for n are in the range of 0..127.

One more small niggle.  The syntax highlighter makes the “@“ turn color only when it is in the first character on a line.  If the line number is anywhere else the "@“ highlighted.  

The TBASIC parser does work correctly and has no issues with where the @xxx line numbers are placed.  The code compiles and runs correctly.

Best regards,

Gary D*ckinson

[support]

Thanks for the report. It is indeed the first time we receive report of this issue.  We will check if we should fix this and let it accept 0-255 or just change the documentation to state that it is valid between 0 and 127. Few people use more than a few of these GOTO labels inside a custom function so 0-127 would be sufficient.

Thanks again.

[support]

We have confirmed that the bug was caused by the conversion of the unsigned byte (0-255) into signed value in Java. This bug was introduced when the original DOS version of TRiLOGI (written in Turbo C) was ported to Java in early 2000, and Java treated "byte" as signed value (Java does not support unsigned anything). So you already know what happened when unsigned value was treated as signed... Anyway this will be fixed in next release of TRiLOGI 6 and 7.

Once again thank you for helping us with the bug report. This is a minor bug that would not affect the PLC program since it wouldn't compile so you get to correct it by using a small n value for the GOTO @n as what you already did.