Hi,
I understand the issues with lcntr and that one cannot use a call
within the last 3 instructions of the end of the loop.
I was reading that there is a way to make a routine return without
forcing a second decrement of the lcntr.
By changing the rts; to an rts (lr);
Has anyone done this, and does this work well for a subroutine that is
called within a loop and also called not in a loop?
I know, I should go try it, but checking to see if people had
successfully used it, or if there are any "uh, don't do it
when...."
info out there.
Thanks,
John Henry KI4JPL
21065L assembler rts (lr) question
Started by ●August 11, 2005
Reply by ●August 11, 20052005-08-11
I looked into that feature a while back, and if I recall correctly, it did
work
as advertised. I think you should be fine using it even if it is not called
from a loop. My understanding is that it prevents the loop counter from being
decremented on return, and if you aren't returning to a loop, the counter
wouldn't be decremented anyway, so it has no affect.
One thing that I do vaguely remember, is that I think it worked as documented
on the hardware, but the simulator still decremented the loop even when the LR
modifier was used. Or maybe there was some other mis-match between hardware
and simulator with the hardware being correct. That is unfortunate, because
the simulator is often the best way to verify "esoteric" behavior such as this.
For me, if I could re-write the loop to avoid the call in the last 3 spots or
could afford a few NOPs, I would probably do that. If not, use the LR modifier
and test it carefully on your hardware to make sure it works as expected in all
cases. I've just used a simple test loop that increments a variable to make
sure the variable gets incremented the number of times the loop is supposed to
iterate.
--- John Henry <jshenry1963@jshe...> wrote:
> Hi,
> I understand the issues with lcntr and that one cannot use a call
> within the last 3 instructions of the end of the loop.
> I was reading that there is a way to make a routine return without
> forcing a second decrement of the lcntr.
> By changing the rts; to an rts (lr);
> Has anyone done this, and does this work well for a subroutine that is
> called within a loop and also called not in a loop?
> I know, I should go try it, but checking to see if people had
> successfully used it, or if there are any "uh, don't do it when...."
> info out there.
>
> Thanks,
> John Henry KI4JPL
__________________________________
as advertised. I think you should be fine using it even if it is not called
from a loop. My understanding is that it prevents the loop counter from being
decremented on return, and if you aren't returning to a loop, the counter
wouldn't be decremented anyway, so it has no affect.
One thing that I do vaguely remember, is that I think it worked as documented
on the hardware, but the simulator still decremented the loop even when the LR
modifier was used. Or maybe there was some other mis-match between hardware
and simulator with the hardware being correct. That is unfortunate, because
the simulator is often the best way to verify "esoteric" behavior such as this.
For me, if I could re-write the loop to avoid the call in the last 3 spots or
could afford a few NOPs, I would probably do that. If not, use the LR modifier
and test it carefully on your hardware to make sure it works as expected in all
cases. I've just used a simple test loop that increments a variable to make
sure the variable gets incremented the number of times the loop is supposed to
iterate.
--- John Henry <jshenry1963@jshe...> wrote:
> Hi,
> I understand the issues with lcntr and that one cannot use a call
> within the last 3 instructions of the end of the loop.
> I was reading that there is a way to make a routine return without
> forcing a second decrement of the lcntr.
> By changing the rts; to an rts (lr);
> Has anyone done this, and does this work well for a subroutine that is
> called within a loop and also called not in a loop?
> I know, I should go try it, but checking to see if people had
> successfully used it, or if there are any "uh, don't do it when...."
> info out there.
>
> Thanks,
> John Henry KI4JPL
__________________________________
