Coverting GOSUB to GOTO?

[James D Jarvis]

Does the compiler convert simple GOSUB commands into GOTO commands?   This little bit of code refuses to die, I thought there would be a stack overflow but nope, not while I was running it.  just keeps wrapping around to -32K and counting back up until it wraps aroundound again and again.

Code: (Select All)

10 Rem bad code...bad
t1 = Timer
20 a% = 0
30 a% = a% + 1
40 Print a%, Timer - t1
50 GoSub 30

[SpriggsySpriggs]

It sounds like it is just overflowing the integer repeatedly.

[bplus]

Can you have a proper GOSUB without a proper RETURN?

I say no.

[James D Jarvis]

Can you have a proper GOSUB without a proper RETURN?

I say no.

That's why I was wondering if the compiler spots it and turns it into a Goto. I had a C/C++ compiler that would do such years ago but I have no idea how to check if QB64 is doing that.

[James D Jarvis]

It sounds like it is just overflowing the integer repeatedly.

Yup. But there's no stack overflow happening like I expected with the gosub unless of course that stack is ridiculously large.  This code is just a version someone else posted in a different basic group to determine when their basic would choke up on this.

[bplus]

Well I just looked at mind boggling 2nd example of GOSUB in WIKI. It suggests you can get away with some sloppy or clever BS depending on your perspective.

Yet there are 2 GOSUBs and 2 RETURNs.

[SpriggsySpriggs]

10 PRINT "HELLO WORLD"
20 GOTO 10

lol

[bplus]

Can you have a proper GOSUB without a proper RETURN?

I say no.

That's why I was wondering if the compiler spots it and turns it into a Goto. I had a C/C++ compiler that would do such years ago but I have no idea how to check if QB64 is doing that.

You do start getting complaints when you do try and add a RETURN. It does behave just like a GOTO otherwise so I think the stack stuff must involve a RETURN in the code.

Oh yeah you can probably catch the C++ interpretation in a temp file

[SMcNeill]

Does the compiler convert simple GOSUB commands into GOTO commands?   This little bit of code refuses to die, I thought there would be a stack overflow but nope, not while I was running it.  just keeps wrapping around to -32K and counting back up until it wraps aroundound again and again.

Code: (Select All)

10 Rem bad code...bad
t1 = Timer
20 a% = 0
30 a% = a% + 1
40 Print a%, Timer - t1
50 GoSub 30

Open task manager.  Run the program.  Watch the memory usage go endlessly upwards.

The climb is slow, but steady, on my machine.  The gosub keeps building return points that it never comes back to, and as it runs, the memory usage goes up, up, and up.   I imagine it'd hit the upper memory limits of a 32-bit OS within about 10 minutes or so.  On a 64-bit OS, I suppose eventually it'd use up available memory, then swap over to running in a swapfile...  until eventually it used up all the space on your hard drive and memory both.   

In either case, I don't think it's the type of results one would want in their code.   If you need a GOTO, use a GOTO, not a GOSUB. 

[SMcNeill]

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.