Coverting GOSUB to GOTO?

[James D Jarvis]

Thanks for the explanation,  I was wondering why it wasn't working like I thought it would.  As for ending quickly... it didn't, over 8 minutes in it was still going but I got bored and stopped it.

[mnrvovrfc]

What are you trying to do with that code? Why does one line in the code have no line number?

Maybe the thread title should be "Convert GOTO to GOSUB so my program dies". (shrugs)

If "GOSUB" is used that way, why not at least keep track of the number of times it was called, and add a condition so it jumps out of the loop and then calls "RETURN" an equal amount of times? One operation or the other should have a purpose.

There's no opportunity even to use "FakeReturn" stunt that Purebasic has, which must be used if "RETURN" is followed by a line label. Which is supposed to prevent either the stack overflow of 16-bit legacy or the chewing up of RAM that is becoming too common in 64-bit systems. I'm not in the mood to request it for QB64PE.

[euklides]

Sub in two modes:

Code: (Select All)

x = 1: flag = 0: GoSub Multip

Print "First pass in gosub mode gives "; x

flag = 1

Multip: x = x * 2
If flag = 0 Then Return


Print "Second pass without gosub mode gives "; x

flag = 0: GoSub Multip
Print "Third pass in gosub mode gives "; x
Sleep

[bplus]

And for those curious about what's going on here, here's how we do GOUBS:

Code: (Select All)

LABEL_50:;
last_line=50;
if(qbevent){evnt(6);r=0;}
do{
return_point[next_return_point++]=1;
if (next_return_point>=return_points) more_return_points();
goto LABEL_30;

RETURN_1:;
return;

You can see that I've copied the translation starting at the label 50:, and went to the jump point.

If you look closely, you'll see that we have a DO statement in there:

DO...
   set a value in our array for our current return point.
   if we have more points than our array can hold, then redim preserve and make the array larger and hold more return points!
   GOTO the jump point
   Set a label for the RETURN to have a place to return to
   ...

And that's basically how we do things.  We use an internal array to hold the return points, rather than using stack space like QB45 used to do back in the day, but it still creates an endless memory leak that's going to end up making your program self destruct over time, if you don't return back from those gosubs.  It just won't do it anywhere near as fast as a QB64 program will. 

Glad to see this explanation too! but I can't tell if this code has found a RETURN place or not. If NOT it's still Not an error because you can end programs in subroutines but if you couldn't, it probably should be an error like having a SELECT CASE without an END SELECT or a SUB without an END SUB.

Update: After running for over 10 minutes the MB's of Memory being used by the little program jumped from 300's to 1,100's and crept up from there. So I can confirm a memory leak, it just takes awhile to kick in.

[James D Jarvis]

What are you trying to do with that code? Why does one line in the code have no line number?

Really just seeing what would happen with the code and wondered what was actually going on when several minutes in the program was still running.  I figured I'd hit a stack overflow but when I didn't I wondered if the complier was dealing with GOSUB as I believed it was.

[SMcNeill]

Glad to see this explanation too! but I can't tell if this code has found a RETURN place or not. If NOT it's still Not an error because you can end programs in subroutines but if you couldn't, it probably should be an error like having a SELECT CASE without an END SELECT or a SUB without an END SUB.

Update: After running for over 10 minutes the MB's of Memory being used by the little program jumped from 300's to 1,100's and crept up from there. So I can confirm a memory leak, it just takes awhile to kick in.

No return in that code.  If there was a RETURN in the qb64 code, the translation would be something simple like a goto RETURN_1;