jumping out of a gosub reminder

[longpole001]

hi guys ,

i am reviewing some old code and updating stucture

I have a need to do a gosub that has a number of program error checks in it

the gosub is called from many places in code to check if the fuction is allowed depending on the hardware status which is read in the error check sub

if no errors are found with the hardware test groups selected in the error check routine then returns to the called section

How ever if it finds an error then it has a direct goto to the service subs and commands branch off to deal with the required error condition , never returning to the orginal routine

this then breaks out of the orginal "return" to calling sub

it not great to do but i can see any way to avoid this , in the structure , and ii know after gosub , a return not done can cause issues

i can avoid the " return " by putting in a series ofg flag so it knows where it was orginally called from but that not a really practical and like to avoid

what i am i forgetting or better way to aproach this

[HenrikOlsson]

There's no real problem to use GOTO (or nested GOSUBs for that matter) from a subroutine to which you've jumped with GOSUB as long as you eventually end up at a "matching" RETURN but you CAN NOT allow the call stack to simply grow because eventually the thing will crash. If the condition you describe happens rarely you might not see the effects of it until after a (very) long time but trust me, sooner or later it will crash.

Don't missunderstand, there can be one GOSUB and twenty RETURN statements in a program, or the other way around, no problems but you can not keep pusing return addresses on the call stack without eventually taking them off.

Instead of that direct goto you mention, why can't you do that as a subroutine?

[longpole001]

"Don't missunderstand, there can be one GOSUB and twenty RETURN statements in a program, or the other way around, no problems but you can not keep pusing return addresses on the call stack without eventually taking them off."

i not seen it crash , but the code did have several goto's to a few other subroutines

most old subs in this code had a error checking of "status test" , to do would be called from many places in the code , some times within several subroutines deep before the error checking routine was called
then if the error check was positive in the routine it would then do a goto another subroutine to a menu and the option it would then show for the error never to return to orginating sub

so from this it would mean the deeper in of other subroutines the error check routine was called would be left on the stack as far as i can see ???

not a good , but never saw a a crash , but maybe that error did not occur perhaps , but seems like its not a thing to be done -


i am reviweing to so that error subs are a goto from the outset , but this then requires a return location from each differnat location its called from , and the more error checkdone in the subrouint the more options of goto creates , but this is really messy stuff

what i would like is the ability to have my return and eat it too , lol , but cant see how that would work as clearing the last "return" address , still leaves all the other return address that may have been stacked prior to the sub that had the goto in it , too bad i cant request a fluch of the stack of the now un need returns - but that just bad programing

just have to redo all the error checking so that is one level or returns to the calling routine and returns i think

[mpgmike]

Here is a simple exercise to review the Stack:

10:  Main:
20:  DO
30:   IF PORTB.1 = 1 THEN
40:      GOSUB CheckIn
'  Stack Contains 40
50:    ENDIF
60:  LOOP

70:  CheckIn:
80:    IF PORTB.2 = 1 THEN
90:      GOTO Verify
' Stack Still Contains 40
100:  ENDIF
110:  RETURN

120:  Verify:
130:    IF PORTB.1 = 1 THEN
140:      RETURN
'  This RETURN jumps to the address in the Stack + 1 (address), so the point of RETURN = 50
150:    ELSEIF PORTB.2 = 1 THEN
160:      GOTO NameCalling
'  Stack Still Contains 40
170:    ENDIF
180:  RETURN

[longpole001]

thanks mike

i am going though this code slowly to find any goto's that have found their way into sub's , fixed about 10 or so that if the error condition happend wold have acted on the goto , and left the stack with the address sitting on there from the gosub

[mpgmike]

I commonly use GOTO to jump from one Sub to another when there is nothing left to do in the first Sub. This keeps the Stack from building up, and reduces execution time. Working with the Nextion TFT screens, sending UART commands must terminate with $FF $FF $FF, which I often add in a subroutine. Since that is the last part of the operation, I GOTO FfFfFf: from the last part of the Send_Data: routine, then RETURN from FfFfFf:. It saves a couple jumps, which may involve ASM BANKSELs.

Know that you are doing it intentionally, know where your Stack is pointing so you know where you ultimately RETURN to, and it can work to your advantage.

[longpole001]

I had similar ideas, but give up on them. I use something like this:
Code:

Gosub xx : If err=1 then goto yy

XX:
if something to triger going to err sub then
err=1 ' goto in different sub after retun
else
err=0 ' return and continue normally
endif

Pedja idea of this is what i was wanting to for error condiions, but the number of options of error check is about 20 or so


what i had was several sub routines that specific error checking set flag and byte values given for the error
each error had a goto another sub routine to show the menu and selection of options to deal with the error found .

The large error sub was called from many locations, at times 3 or 4 subs deep in code to check the status of hw to see if that option was ok ,
if it was ok it would return , but if the error was need to be serviced then a direct would goto the " service routines and the options presented " NEVER TO return to the location , it would then run the error service options , a restart was often done after the error was checked / fixed

what i have done now is not have any goto , just close all the returns back to start , then runs the error service routines - its probably nicer , but a lot more work and code at some points that , just doing a goto and service the error

[pedja089]

You could just goto error handler if you found error. Then make just one exit of it, and exit with @ Reset.
This will reset PIC and clear stack. Same way as if you power off then on.

[longpole001]

yes some of the options force a reset