I have a program that would be much easier to make if I use a recursive subroutine. What I mean by this is Inside of one subroutine, there is another subroutine that references the first subroutine inside of itself. Is that bad? I can think of a way around it, but it makes the code oh so much less readable and understandable, since there will be an End before its connected While, and that too may throw errors

yeah, but now it's not letting me compile. It might be something else, but ergh.

So a safeguard could be just having several Returns at the end of the program, right?

Perhaps. Having a while before an end also might cause problems, depending on how it detects proper block setups. The issue is, it's currently structured like so:

lbl Main Sub
Blah
Blah Blah
If ...
sub(other
end
Return

lbl other
blah
blah blah
Repeat Getkey(x)
sub(Main)
end
blah blah
Return

The If that triggers the "other" sub will not be triggered again until after the sub has reset itself (after the repeat's End) , so....it should work.

I see a lot of potential for screwing up the stack with that structure. Could you give us some context on why it would be difficult to do it any other way?

Don't worry, right now I can afford a little speed loss. Also, as of right now I see a max of 3 nests, meaning 4 subroutines at once And there are going to be few variables. This is for my battle Engine, BTW. The subs are recursive so it can wait for a buttonpush to allow you to attack while time still increases, to allow for double and triple techs between party members. Fortunately, monsters will not need this setup.

Edit: Double ninja

Like I mentioned, I could also do it with a while loop, but it would be much more complicated, and therefore be more buggy

By the way, the if that triggers said "other" subroutine is a direct part of that subroutine's function, and, if written without glitches, it should function exactly as intended.

Want some context?

Battle starts, time starts going up. One person reaches full time, it triggers the If, and goes to the "other" sub with a few vars set. The "other" sub then reactivates the main Time Increment subroutine so that other players can have their time increase, but it does so while checking with a Repeat Getkey for 1, 2, or 3 to be pressed, respective to the player whose time is full. The If is an = check, so once time goes over with the next increment it will not be triggered for the same player until their "Other" loop resets their time to 0.

Too many returns will not crash your calc, but it will not fix the issue either.

Doesn't Axe Push PC onto the stack, then pop it with Return? If that's the case, then too many returns will pop a random byte into PC, which may or may not contain valid code.

Oh, I'd forgotten about that. One of the optimizations in the documentation is to not add a Return to the end of the program

Its actually not auto optimized anymore due to the possibility of memory leaks i believe in included programs