Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: willrandship on December 23, 2010, 12:47:02 am
-
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 XD
-
In Axe or ASM, it's not bad as long as you ALWAYS return from each subroutine by the end of the code. If you don't, then you're going to crash your calc.
-
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?
-
No. Too many returns will also crash your calc. One subroutine call, one return. If they do not match up, you're probably going to clear your RAM. Axe might not want to compile because it doesn't see that you're calling the routine more than once before returning.
-
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.
-
Recursive subroutines are great and often reduce the size of the program a lot. The drawback is that they are generally a little slower and there is a limit to how many nested subroutines and pushed variables you can have before you get a stack overflow which crashes the calc.
-
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?
-
Too many returns will not crash your calc, but it will not fix the issue either. The only way to make sure that your calc doesnt crash is to make absolutely sure that you return all the way out of every subroutine. As long as you don't recurse infinitely into the same subroutine, and as long as you don't call it over 9000 times, just put a return at the end of your subroutine and you should be perfectly fine.
-
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 :P 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 :P
Like I mentioned, I could also do it with a while loop, but it would be much more complicated, and therefore be more buggy :P
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.
-
No. Too many returns will also crash your calc. One subroutine call, one return. If they do not match up, you're probably going to clear your RAM. Axe might not want to compile because it doesn't see that you're calling the routine more than once before returning.
too many returns would crash your calc if you were, say, trying to calculate the 50th fibonacci number recursively.
willrandship, as long as that If statement won't trigger while lbl other has been called, you're fine.
-
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.
-
Too many returns can't crash your calc, too many calls can however. Like for example:
Lbl Sub
Disp "HI
Return
Return
Return
Return
Calling this subroutine won't crash because only the first Return will be experienced. No matter how many returns you have, at the very *most* you will return to where you started, which is a safe place. The only ways a crash can happen is if you call too many times and run out of stack space, or if you don't return enough and end up in a weird place
-
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 :P
-
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 :P
that's an auto-optimization already.
-
Its actually not auto optimized anymore due to the possibility of memory leaks i believe in included programs
-
Quick question: if you have an Axe-based Axiom (compile, disassemble into asm, compile as an Axiom) will it be able to access variables defined in the programs that run it?