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
__________________________________