Nesting JSR commands

[Avram]

Can I nest multiple JSR jumps? For instance, if I JSRed to a routine, and then JSRed again to another routine before returning from the first, would I cause problems? And is it bad programming practice?

[Bryan]

That's perfectly okay. The stack is 256 bytes long, so it can theoretically support over 120 nested routines if you don't push a whole lot of variables to the stack.

 

It's common to see software that goes down several levels. For example, a program may well be broken into several main subroutines:

 

Update graphics

Update sounds

Read inputs

Move players

Perform enemy AI

etc...

 

The program would run these subroutines in the specified order, and each routine may call many other routines to perform various sub-tasks. Those routines may call things like math function routines or the like so you can easily end up several layers deep. The stack will grow as you JSR and shrink as you RTS your way back out.

 

Remember that for speed-critical code, it may be better to put simple functions inline rather than call a routine over and over, even if it makes the code more redundant.

 

Also, interrupts act kinda like a forced JSR- jumping the processor to the interrupt code and then returning to your program. The main difference is that the status register is saved on the stack as well as the return address requiring 3 bytes of stack space instead of 2.

Edited May 10, 2011 by Bryan

[Avram]

Thanks Bryan. My program kept freezing due to what I assumed was nested JSRs. After I posted my question here I discovered the bug was something else completely. But thanks for answering my question - it's good to know that I can nest JSRs after all.

[pps]

Don´t forget to save/recall the accumulator, x and y registers, if you don´t want to get some strange bugs when nesting several routines "together"

[Bryan]

Don´t forget to save/recall the accumulator, x and y registers, if you don´t want to get some strange bugs when nesting several routines "together"

I'm confused by what you mean. You only need to save registers in an interrupt routine that can happen between any two instructions and must return the CPU to the original (pre-interrupt) state.

 

For any other routine the code just before the JSR can place any values it needs to save in RAM, either directly or via a PHA, JSR, PLA. Sometimes I try to make simple subroutines leave X or Y or both alone so I can leave values in those registers to use after the JSR/RTS. This is when commented code is your friend.

[Sheddy]

Kinda off topic, but I just wanted to say that I'm really glad you've found the time to get into the coding, Avram

[Avram]

I've been trying to make subroutines fairly self contained. So far I've found that defining bits of memory and modifying them seems to be safe. But yes, I'll be careful when jumping from routine to routine.

 

Im hoping to get back into DLIs quite soon once I've gotten my simple platform engine doing everything I want it to. AS I recall, that's when I need to worry about pushing and pulling onto the stack.

 

Thanks Sheddy. Were it not for your AtAsm and Crimson Editor guide I don't think I would have ever gotten back into programming! Oh, and your game's looking marvelous by the way!

[pps]

Don´t forget to save/recall the accumulator, x and y registers, if you don´t want to get some strange bugs when nesting several routines "together"

I'm confused by what you mean. You only need to save registers in an interrupt routine that can happen between any two instructions and must return the CPU to the original (pre-interrupt) state.

 

For any other routine the code just before the JSR can place any values it needs to save in RAM, either directly or via a PHA, JSR, PLA. Sometimes I try to make simple subroutines leave X or Y or both alone so I can leave values in those registers to use after the JSR/RTS. This is when commented code is your friend.

Just that is what I meant. Forgotten that, you might get strange things.