| |
Dosoo
Account closed
Registered: Apr 2002
Posts: 32 |
?stack overload error
Those of you who have downloaded my Amebas preview may notice some ugly methods I used to make it work. That made me think of situation which might be possible, but I would like hear an opinion from a more exprerienced coder.
Is there a possibility that using several subroutines and interrupts may cause stack to overload? This is vital information for my project, as I think every time in the Amebas game when new shooter is initialized there is one return address that remains in the stack. That's because at the end of an interrupt there is jmp to the main code loop instead of RTI.
The code works OK, but is there a possibility that after several shots the stack overloads and code becomes unstable? Tell me what you think? Have you ever encountered such a situation?
Any comment appreciated |
|
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
How about pulling some data off the stack that the interrupt puts on there then JMPing to whereever? I've had stack issues in the past where I put more on than I pull off. Once balanced it was ok. |
| |
CyberBrain
Administrator
Posts: 392 |
The stack can easily overload. There are only 256 bytes for the stack, so if you try to push more than 256 bytes on the stack, it will overwrite the first bytes of the stack.
So if you shoot enough times you code could crash. (allthough i actually wonder if it would in your case, coz it sounds like you wouldn't use the first bytes for anything once the overflow happens - but unless you're sure, maybe pretty code is better, unless it REALLY optimizes something.. saving 6 cycles for the RTI isn't that much imo) |
| |
MorGorr
Account closed
Registered: May 2002
Posts: 47 |
You will have to insert a couple of PLAs in the appropriate place to rid the stack of those garbage bytes. |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
Or sometime like TSX, INX for however many bytes need to be removed then TXS. Same cycles as 2x PLA and after that you save. Only lose on bytes used. |
| |
Dosoo
Account closed
Registered: Apr 2002
Posts: 32 |
Let it be noted, that when I have tested the code the stack overload hasn't happened yet. Maybe I should try to play longer.
But that information, that stack resets after overflow is relieving information, in case the bytes that are lost are the first, NOT the last bytes. In my theory my code leaves only one address in stack that is not removed. After that is JMP instruction and after that a new interrupt is set.
Using the information you've given me the stack slowly fills with that same address and although it's ugly coding, the code itself stays stable. That's my theory. Only way to test it is to play my game...
And what comes to ugly code, in my case it doesn't optimize, but it was the only way I could think of to solve a precalculation problem.
Advert: Download Amebas preview in this site and comment the whole game ;) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
why not test it by putting the stack pointer on the screen?
that way you can keep track of it's value while playing the game.
so just :
tsx
stx $0400
or you can even write it out nicely if that's too unreadable for you.
if you notice it's dropping, you're making stack-garbage. Just pull enough bytes from the stack in that case (pla pla for 1 irq/jsr) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
at first: you absolutely shouldnt do things like jumping into the main code from the irq...
secondly: but afterall you did it so... you can:
do pla pla pla after the jmp, to take out of the stack the return adress (2 byte) and the status register (1 byte), so the stack pointer will have the same value as it would have after rti.
...in c64 machine code it doesnt really matter if the stack overflows, the stack pointer just wraps around and nothing happens unless it writes over some return adress(es) you would need later on.
if after every irq you jump to the main loop, and you dont need to return to the subroutines where the irq happened, your solution may work fine without taking care of what the stack does. (unless your main loop is not a subroutine :) |
| |
Dosoo
Account closed
Registered: Apr 2002
Posts: 32 |
Thanks for the info.
I know I shouldn't do that kind of code and I'm thinking of other solutions. However my game needs calculations and I think it's more user-friendly to use every single clock cycle for calculating instead of calculating one digit per interrupt so that the code remains beautiful.
Coding continues |
