PAGESEL:
For use when generating an object file. An instruction to the linker to generate
page selecting code to set the page bits to the page containing the designated
<label>. Only one <label> should be specified. No operations can be performed on
<label>. <label> must have been previously defined.

So it is intended to work with the linker, I haven't tried it within regular
code.

-Adam

"Quitt, Walter" wrote:
>
> Isn't that what the PAGESEL directive does??????
>
> -----Original Message-----
> From: M. Adam Davis [mailto:adavis@UBASICS.COM]
> Sent: Thursday, April 13, 2000 7:26 AM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: Program over 1k with a 16F877
>
> When you are about to cross page boundaries, usually you end up putting the
> less-frequently used code modules in the second and later pages, and you try
> to
> stay within a single page as much as possible.  If you are building a
> network
> node, for instance, you may want to put your serial input and packet
> handling
> routines all in the second page.  When a packet comes in, you'll spend the
> bulk
> of your time there, instead of jumping to and from the first page or other
> pages.
>
> The only thing you need to do to jump into a different page is load PCLATH:3
> & 4
> with the two upper bits of the new page before executing the jump
> instruction.
>
> You don't need to change the pclath for returns since the full address of
> the
> location to return to is stored on the stack.  PCLATH retains its last
> setting,
> so if you set it for the second page, jump to it, and return from it, your
> next
> call or goto will also go to the second page unless you reset the PCLATH.
> This
> is useful for staying in the 'current' page if you are careful about not
> changing the PCLATH during interrupts and in other functions.
>
> On the part in question, the PCLATH bits you need to know about are bits 3
> and
> 4.  The lower bits (0-2) are not used in gotos and calls and are ignored
> (they
> are used when you write to the PCL).  PCLATH is just a holding register, and
> will never be referenced until a CALL, GOTO, or writing to PCL.
>
>         ORG     0
> Start                           'This resides in the first page.  Calls to
>                                 'functions past this page need PCLATH
> updated.
>         CALL    FuncIn1stPage   'Jump to function that starts in this page
>
>         MOVLW   B'00001000'     'Next call will go to the second page
>         MOVWF   PCLATH
>         CALL    FuncIn2ndPage
>
>         MOVLW   B'00010000'     'Next call will go to the third page
>         MOVWF   PCLATH
>         CALL    FuncIn2ndPage
>
>         MOVLW   B'00011000'     'Next call will go to the fourth page
>         MOVWF   PCLATH
>         CALL    FuncIn2ndPage
> ...
> ...
>         ORG     0x7FF           'This next function will cross page
> boundaries
>                                 'Which is fine, the program counter can
> handle
>                                 'that, and it won't mess the return up.
>                                 'Do not allow computed gotos to cross page
>                                 'boundaries, though, without thinking of
> PCLATH
> FuncIn1stPage                   'This function starts in the first page, but
>                                 'crosses into the second page.
>         MOVLW   .42             'Don't Panic!  This instruction is in the
>                                 '1st Page
>         ...
>         MOVLW   B'00001000'     'This instruction is in the second page.
>         MOVWF   PCLATH          'Since we are in the second page now we
> don't
>         CALL    FuncIn2ndPage   'need to set the PCLATH, right?  Wrong. So
> why
>                                 'did we set it?  The PCLATH hasn't changed.
>                                 'Whatever was in it before is still in it,
>                                 'and will affect our calls and gotos.
>                                 'In this case, the last thing that modified
>                                 'it before this function was the device
> reset,
>                                 'which always makes it b'---00000'
>                                 'If we use a jump or call before setting it,
>                                 'we'll end up somewhere in the first page.
>         RETURN                  'This instruction is in the second page
>
> FuncIn2ndPage                   'Function starts in the second page
>         MOVLW   B'00000000'     'Next call will go to the first page
>         MOVWF   PCLATH
>         CALL    FuncIn1stPage
>         RETURN
>
>         ORG     0x1000          'Function starts in the 3rd page
> FuncIn3rdPage
>         ...                     'If you are in the third page, and you jump
>         MOVLW   B'00010000'     'to another third page location, you can
>         MOVWF   PCLATH          'probably assume that the PCLATH contains
>         CALL    SubIn3rdPage    ' B'00010000' because we had to do that to
>                                 'jump into the third page before.  But I
>                                 'wouldn't assume that myself, unless I
>                                 'absolutely HAD to save those two extra
> cycles.
>                                 'If you execute a call or goto without
> knowing
>                                 'what's in PCLATH, you can end up in the
>                                 'weirdest places, and debugging is a living
>                                 'nightmare...
>                                 'Tis better to be safe than sorry.
>         RETURN
>
> SubIn3rdPage
>         ...
>         RETURN
>
>         ORG     0x1800          'Function starts in 4th page
> FuncIn4thPage
>         ...
>         RETURN
>
> I think this covers about all the bases you need to know to cross page
> boundaries.  This information was taken from the 16c6x data sheet, section
> 4.3
> p.48 on PCL and PCLATH.  Before you start writing code based on what I've
> written above, read that section (it's short) or the similar section in the
> 16f8xx sheet.
>
> I hope this helps!
>
> -Adam
>
> David Thompson wrote:
> >
> > Hi guys,
> >
> > My program is rapidly approaching the 1k mark and there is still a lot of
> > code to write. The development system uses a 16F877, but the final design
> > will probably use a smaller PIC - maybe a 16C73.
> >
> > The question is, are there any things to look out for when crossing page
> > boundaries (2k with these chips, I think), or more particularly, are there
> > any tricks to lessen the hassle of doing so?
> >
> > I've seen macros to do "long calls" and that kind of thing, which is why I
> > am asking.
> >
> > Thanks,
> >
> > Dave.