In 17C code, the following seems to work best.
Also, in 17 code a return is a return is a return.
In 16 code, I could come up with something too.
Just never had to, yet.  The macro should get
the idea across.  Ditch the references to interrupts
if you don't use them.  As stated, the following
works very well for me.

;***************************************************************
;* Macro   LONGC           ;Long Call
;***************************************************************
LONGC MACRO SUBROUTINE

   bsf     CPUSTA,GLINTD       ;interrupts off
   movlw   HIGH (SUBROUTINE)
   movfp   WREG,PCLATH         ;Z unaffected
   bcf     CPUSTA,GLINTD       ;interrupts on
   lcall   LOW  (SUBROUTINE)

   ENDM

-----Original Message-----
From: Erik Reikes [mailto:ereikes@XSILOGY.COM]
Sent: Friday, January 14, 2000 10:42 AM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: 16f84 & 16f877 branching


At 11:17 PM 1/13/00 -0700, you wrote:
>>From what I have (mis)read, branching instructions for these cannot
always
>address 'distant' locations. If this is the case, then when exactly
does a
>Call, Goto, or Return/Retfie require special handling, and how would I
know
>I've not done this when I should have?

Any time you cross a code page boundary you must manually set the two
code
page bits in the PCLATH.

If you take a look at the goto and call type instructions you will
notice
that they only have an 11 bit address field, giving you 2k to jump in.
Something else to note, this address is absolute in the current code
page,
that is, it is not a relative jump from where you are, but absolute in
the
code page.

I'm not sure if returns keep the whole address on the stack or what.  I
write in C, and typically my compiler takes care of all that stuff.

-Erik Reikes
Erik Reikes
Software Engineer
Xsilogy, Inc.

ereikes@xsilogy.com
ph : (858) 535-5113
fax : (858) 535-5163
cell : (858) 663-1206