I wrote:

> > By the way, don't bother using the "LCALL" pseudo-op... Since it
> > doesn't restore the code-page bits after the CALL, it's sorta
> > useless.

and G.Daniel Invent Design <g.daniel.invent.design@xtra.co.nz> wrote:

> Ah Ha !
> I've caught you out !

    I'm afraid you haven't, G.Daniel... You've simply missed my
    point.

> stack is taken from actual location at a CALL or LCALL. stack is
> wider than PCL, includes  non R/W  PCH bits. When you set program
> page select bits, these do not take effect until the actual jump or
> call at which time a special internal operation transfers them to
> the the otherwise non R/W PCH register.
>
> Easy english: LCALL does not spoil return address on stack.

    Yes, I know... My point was that after the RETURN (to the
    correct address), the PCLATH register will still contain the
    value stored in it before the LCALL.

    The next GOTO or CALL instruction encountered by the PIC,
    therefore, will cause a branch to a location on the same page as
    the subroutine that was LCALLed.  For example:

            ORG     0x0000

            LCALL   A800
            GOTO    A50

            ORG     0x50

    A50:    NOP

            ORG     0x800

    A800:   RETURN

In the above code fragment, the LCALL branches to address 800, then
the RETURN (correctly) points the PC back to the GOTO. Because the
PCLATH register wasn't restored after the CALL, however, the GOTO
branches to address 850 rather than to address 50.

That's why I recommend against using LCALL; it's much safer to just
write your own "long CALL" macros to adjust PCLATH before _and
after_ the CALL.

-Andy

=== Andrew Warren - fastfwd@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499 (personal)
=== http://www.netcom.com/~fastfwd (business)