Gosub "nesting" question???

OLDmarty

Senior Member
Hi all,

I read that gosub commands can be nested upto 8 times in a stack. (using an X2 chip)

So, just to confirm:

Assuming my main code (do-loop) calls up another block of code (lets call it "gosub 1") and then within that block of code i THEN call up "Gosub 2" to process some other code.
When i use the RETURN command, will it return me back to the Gosub 1 block of code? or will it return me back to the MAIN code (do-loop)?

I *think* it will return me back to Gosub ONE, but i just wanted to be sure i'm understanding this the right way.

If i understand right, with 8 nested Gosubs (X2 chips), i can call upon 7 other gosubs from the first gosub (gosub1 calls gosub2 calls gosub3 right upto calling gosub8, and then a 'return from gosub8 code should take me back to gosub 7's block of code etc???

Thanx in advance.
Marty
 

inglewoodpete

Senior Member
A return statement will return execution to the command immediately following the GoSub that called the subroutine that the return statement is in. (phew - that was a big breath!)
 

OLDmarty

Senior Member
A return statement will return execution to the command immediately following the GoSub that called the subroutine that the return statement is in. (phew - that was a big breath!)
Thanks for confirming my thoughts, i just wanted to be certain ;-)
 

AllyCat

Senior Member
Hi,

Yes the RETURN always takes the program back to the previous "level", but you should normally limit the depth of Subroutine CALLs to 7 because an interrupt may need the 8th return address.

Sometimes that can be a problem if you need to "escape" from the subroutines, for example if a serious error occurs (so there is no point in contunuing the present calculation), or an immediate user-response is needed. Unfortunately with PICaxe, not much other than a full RESET can (or at least "should") be done.

A "trick" that I soimetimes use (no doubt frowned upon by serious programmers) is to jump into a subroutine and then the RETURN takes the flow back to the next higher level (faster than two separate Returns). Here's an example (to run in the simulator) which "prints" bytes as ASCII-Hex character pairs and recovers correctly if an error occurs (i.e. w1 > 1 byte).
Code:
#terminal 4800
pause 5000
	sertxd(cr,lf)
do					; w1 = 0 after a Reset
	sertxd(" $")
	call showbyte
	inc w1
loop	
showbyte:
	b1 = w1 / 16			; First nibble
	call shownib
	b1 = w1 and 15			; Second nibble, then "fall into" subroutine (= GOTO)
shownib:
	if b1 > 15 then goto error
	b1 = b1 / 10 * 7 + b1 + 48	; Calculate ASCII-HEX character
	sertxd(b1)
return
error:
	reset
Two return addresses (levels) on the stack, but only one Return ! ;)

Cheers, Alan.
 

westaust55

Moderator
An alternative to the RESET command is to use RUN 0.
This will preserve the variables, whereas RESET = RUN 0 + clear variables.

If you can detect an error condition, the RUN 0 option gives you a chance to set a flag, start again with preserved variable and announce the error (SEROUT or other means) and continue.
 

hippy

Technical Support
Staff member
you should normally limit the depth of Subroutine CALLs to 7 because an interrupt may need the 8th return address.
And, when interrupts are enabled, you will have to limit the depth further if the interrupt itself uses GOSUB's and calls its own subroutines.
 

OLDmarty

Senior Member
Thanks guys for all the extra comments and advice.

I doubt i will ever (hopefully) need to go so many levels deep in the gosub nest.

My OP was merely to confirm my understanding of the nesting and getting back out with returns and where it would take me.

Good to know the extra depth and interrupt issues etc ;-)

Thanks.
 

AllyCat

Senior Member
Hi,

An alternative to the RESET command is to use RUN 0.
Ah, I wondered why I hadn't really "encountered" that alternative (and I do concede that the OP specified an X2), but it doesn't work on an 08M2, nor any M2 in PE5. :( Which rules out >95% of my normal programming. ;)

The compilier does helpfully suggest to " try 'restart' ", but I haven't (yet) found any chip which accepts that. :confused:

Cheers, Alan.
 
Top