Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Hot_Dog on May 31, 2011, 02:08:56 pm
-
Suppose I had the following code (basically an endless loop):
Lbl A
sub(B
Lbl B
Goto A
Is this bad?
-
Yes, it's bad. It'll cause a stack overflow, and then random things start happening because data is being executed.
-
Lbl A
sub(A)
Same thing :D
sub( is basically just CALL. That's all it is.
-
Lbl A
sub(A)
Same thing :D
sub( is basically just CALL. That's all it is.
So that's not like Pause 0, it's really infinite or does it break or something?
-
Its okay if you have a base case and you've set it up to be a recursive call. For instance, you could write a factorial function like this:
Lbl A
If r1=0
Return 1
End
Return r1*sub(A,r1-1)
Anyway you just have to be careful about those. The less goto's you have in your code, the less likely you will leak. Most uses of Goto can be replaced by either loops or subroutines without sacrificing speed or size.
-
Lbl A
sub(A)
Same thing :D
sub( is basically just CALL. That's all it is.
So that's not like Pause 0, it's really infinite or does it break or something?
Pause is really a bunch of jumps (DJNZ and JR, to be exact). sub( is different because it's CALL, which uses the stack. You know what happens when you overload the stack ;)
-
I also found Asm(3333 to work :P
-
I also found Asm(3333 to work :P
Yeah, randomly increasing the stack pointer does seem to have that affect.
And compiling the "Lbl A:Sub(A)" thing shows that it is in fact, just a straight call back to 9D95.
-
I also found Asm(3333 to work :P
Yeah, randomly increasing the stack pointer does seem to have that affect.
And compiling the "Lbl A:Sub(A)" thing shows that it is in fact, just a straight call back to 9D95.
Lol, I meant increasing the stack pointer fixes the problem
-
I also found Asm(3333 to work :P
Yeah, randomly increasing the stack pointer does seem to have that affect.
And compiling the "Lbl A:Sub(A)" thing shows that it is in fact, just a straight call back to 9D95.
Lol, I meant increasing the stack pointer fixes the problem
Oh, right, stack grows downward. This is why I can never really be a great z80 coder. I can't remember stupid details like that!
-
I hear "Memory leak" a lot and generally know what it is on computers, but is it permanent memory loss on Z80 calculators?
-
I hear "Memory leak" a lot and generally know what it is on computers, but is it permanent memory loss on Z80 calculators?
When you are programming for calculators (actually for anything, but calculators in particular), you require memory for loops and subprograms. The more unexited loops and subgrams you are running at once the more memory you need. Eventually you reach a point where you run out of safe-to-use memory. You don't lose the memory for good, but your calculator does crash or can't run anymore.
-
Depends on the context. In BASIC a "memory leak" (caused by Goto'ing out of a loop) causes a minor leak that is returned when the program exits. In Axe and ASM, a memory leak is a bit more serious, but it still doesn't usually crash or anything. It just means a small portion of your RAM is unavailable because your calculator thinks it's still being used, and it gets fixed when you RAM clear. But in this case, if you keep using sub( (or CALL) over and over, you cause a type of memory leak that could lead to a stack overflow, which finishes off in a nice little crash. None of it's permanent, though.