> David Cary <PICLISTspam_OUTMITVMA.MIT.EDU> wrote:
>
> > Did you know about the
> >   LCALL
> >   LGOTO
> > pseudo-ops ? They do everything your page macros do, and they're
> built
> > into MPASM.
>
> David:
>
> MPASM's LCALL pseudo-op doesn't restore the page bits after the
> subroutine return.
>
> -Andy
>
> === Andrew Warren --- @spam@aiwKILLspamcypress.com
> === IPD Systems Engineering, CYSD
> === Cypress Semiconductor Corporation
> ===
> === Opinions expressed above do not
> === necessarily represent those of
> === Cypress Semiconductor Corporation
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics

> David P. Harris <RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU> wrote:
>
> > Why particularly do we need to restore the page bits? I thought
> > these are only important when: doing a long call, long goto, or
> > otherwise manipulatiing the PCLATH register
>
> David:
>
> The PIC doesn't know that you're doing a "long" CALL or GOTO, so it
> would be more accurate to say that the page bits are important "when
> doing a CALL or GOTO".
>
> If you think of it THAT way, it's clear that the page bits must be
> set correctly before EVERY CALL or GOTO.  If the page bits weren't
> always pointing to the current page -- that is, if you just left them
> set to some other page after a long CALL -- then you'd have to
> explicitly set them before each CALL or GOTO; in other words, EVERY
> SINGLE GOTO OR CALL would have to be written as a long GOTO or long
> CALL... Which would be monumentally wasteful, since most GOTOs and
> CALLs are to addresses in the current page.  The waste is compounded
> by the fact that "skip" instructions won't skip over long GOTOs and
> CALLs properly... Which also means that even if you DO make all your
> CALLs and GOTOs long, your code won't work.
>
> Imagine, for example, that you wanted to do this:
>
>          ORG    [somewhere on page 0]
>
>          LCALL  PAGE3_SUB
>          BTFSC  RETURNED_BIT
>          GOTO   BIT_SET
>
>          NOP
>
>      BIT_SET:
>
>          NOP
>
> How would you make that "BTFSC/GOTO" combination work if you didn't
> restore the page bits between the LCALL and the BTFSC?
>
> If, on the other hand, you restore the page bits after a CALL or a
> long table-lookup, then they always point to the current page and all
> your same-page GOTOs and CALLs can be written normally.
>
> -Andy
>
> === Andrew Warren - fastfwdEraseME.....ix.netcom.com
> === Fast Forward Engineering - San Diego, California
> === http://www.geocities.com/SiliconValley/2499
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

>From: William Chops Westfield <.....billwspam_OUTCISCO.COM>
>Reply-To: Bill Westfield <TakeThisOuTbillw.....TakeThisOuTcisco.com>
>To: TakeThisOuTPICLISTKILLspamspamMITVMA.MIT.EDU
>Subject: Re: [PIC]: Page Switching Problem
>Date: Thu, 19 Apr 2001 20:30:17 PDT
>
> > [Olin's paging macros]
> > I've described this a number of times before, although in less detail.
>I
> > get the impression that I'm preaching to deaf ears, but I'm not sure
>why.
>
>I think the problem is that a lot of people are used to code examples that
>run entirely in a single page, so they don't need to worry about pclath at
>all.  There's a congnitive jump involved going from not worrying about
>pclath at all, to using it everywhere - a sort of "I only added one
>function
>in page1 and now I have to use the lcall macros everywhere?  I don't get
>it!"
>
>It's a bit like programming in C with the old 8086/80286 compilers.  All
>sorts of effort went into "small" and "medium" compile models that
>conserved
>(some) memory and execution speed by not paying attention to the segment
>registers.  People got themselves into all sorts of trouble because some
>functions would eventually end up beyond one of those 64k limits, and
>they'd
>mix their models together.  Things would have been a lot easier to just use
>entirely "huge" model semantics that always paid attention to the segments.
>
>The "problem" is particularly visible on small microcontrollers - people
>hate to "waste" memory if they can possible avoid it.  In fact, of course,
>if you just crossed that page boundry, then you have a LOT of program
>memory
>available - double what you're using so far.  And in a microcontroller
>environment, your code either fits or it doesn't - there's none of this
>"runs out of memory if quickkeys is installed", or "requires a system with
>the 256k memory upgrade to run at all."
>
>Olin - do you have a methodology for "squeezing" out the extra page
>handling
>code if you're really tight on bytes?
>
>BillW
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.
>
>

> First, I use the linker.  I don't know why more people don't do this since
> it's easy and has a number of advantages.  Most of the code I see here has
> ORGs in it, indicating that the assembly is in absolute mode.  I have NEVER
> yet used absolute mode.  The big advantage of using the linker is that code
> can be in separate modules.  This makes things much more maintainable and
> reusable.  Each module also gets its own namespace for local symbols, so you
> don't have to worry about name collision with some unrelated part of the
> code.  You can now group functional blocks into separate modules.  This also
> provides a natural place to document the interfaces between the functional
> blocks.
>
> Since the code is now a collection of relatively small modules, you can
> dictate that each module must be entirely on one page.  I do this by setting
> up a separate linker section for each code page.  Except for the code at the
> startup location and the interrupt routine, I just let the linker stick a
> module wherever it wants to.  It does this quite nicely based on a best fit
> algorithm.  I have never yet had a code module that was bigger than a page,
> or even close to it.  I have had data modules bigger and handled that by
> making separate one-off exceptions in the linker control file for that
> project.  I've only had to do that once in over two dozen PIC projects, and
> that happened to be a personal project.
>
> Now that the code within a module is all guaranteed to be on the same page,
> I use the convention that PCLATH is always pointing to that page.  It is the
> responsibility of the caller (or GOTOer) to set PCLATH to the new page.  I
> can forget about PCLATH when doing GOTOs and CALLs within a module.  To call
> a global routine in some other module, I use the GCALL marco.  This sets
> PCLATH before the call and restores it after.
>
> The GCALL and other macros are in STD.INS.ASPIC which can be found at
> http://www.embedinc.com/pic.  This page also describes a bunch of "standard"
> modules I use with most PIC projects and provides template modules where you
> can fill in the blanks to make your own PIC project.  These are the same
> template files I use when creating a new project.  Click on the "HAL example
> project" link to see the modules and source code for a real project.  You
> can see that the executable part of this project was broken into 9 separate
> modules.
>
> I've described this a number of times before, although in less detail.  I
> get the impression that I'm preaching to deaf ears, but I'm not sure why.
> Do others think my method is silly, don't "see the light", have something
> better, don't understand the description, don't think it solves the problem,
> or what?  I don't think it's lack of interest because this issue of PCLATH
> and code pages seems to come up every week or two.  Meanwhile I'm cranking
> out reliable, maintainable PIC projects without wasting time on PCLATH bugs.

> > I am also
> > interested in learning more about the linker too
> > if anyone has advice or online info.
>
> I guess I should put build scripts and such on my web site.  Some day
> <sigh>.  For now maybe this will help.  This is my default linker control
> file for the 16F876 (my favorite "universal" PIC):
>
> //   Linker control file for the PIC 16F876 processor.
> //
> CODEPAGE NAME=config START=0x2007  END=0x2007 //special processor config word
>
> CODEPAGE NAME=code0      START=0  END=0x7FF //code page 0
> CODEPAGE NAME=code1  START=0x800  END=0xFFF //code page 1
> CODEPAGE NAME=code2 START=0x1000 END=0x17FF //code page 2
> CODEPAGE NAME=code3 START=0x1800 END=0x1FFF //code page 3
>
> DATABANK NAME=bank0  START=0x20  END=0x6F //register bank 0
> DATABANK NAME=bank1  START=0xA0  END=0xEF //register bank 1
> DATABANK NAME=bank2 START=0x110 END=0x16F //register bank 2
> DATABANK NAME=bank3 START=0x190 END=0x1EF //register bank 3
>
> SHAREBANK NAME=globalram  START=0x70  END=0x7F PROTECTED //global regs, bank 0
> SHAREBANK NAME=globalram  START=0xF0  END=0xFF PROTECTED //global regs, bank 1
> SHAREBANK NAME=globalram START=0x170 END=0x17F PROTECTED //global regs, bank 2
> SHAREBANK NAME=globalram START=0x1F0 END=0x1FF PROTECTED //global regs, bank 3
>
> SECTION NAME=.udata_shr RAM=globalram //global memory mapped to all register banks
> SECTION NAME=.BANK0 RAM=bank0 //for registers explicitly in bank 0
> SECTION NAME=.BANK1 RAM=bank1 //for registers explicitly in bank 1
> SECTION NAME=.BANK2 RAM=bank2 //for registers explicitly in bank 2
> SECTION NAME=.BANK3 RAM=bank3 //for registers explicitly in bank 3
>
> ********************************************************************
> Olin Lathrop, embedded systems consultant in Littleton Massachusetts
> (978) 742-9014, EraseMEolinRemoveMESTOPspamembedinc.com, http://www.embedinc.com
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email RemoveMElistservKILLspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> nit-pick:
>
> --- file std.ins.aspic at http://www.embedinc.com/pic
> ...
> setpage  macro   adr
> ...
>          pagesel adr
>   if fam_16 && (ncodepages == 2) ;need NOP bug workaround ?
>          nop
>     endif
> ...
>
> Um, I've deleted that ``nop'' in my copy of that file. This works for me

> A page transition will happen somewhere in the code.  What if
>
> loop  blah
>       blah
>       btfsc ...
>       goto  loop
>
> and the page transition happens to come between LOOP and the GOTO
> LOOP?  As I understand your method, there is nothing to handle and
> fix this.

> First, I use the linker.  I don't know why more people don't do this since
> it's easy and has a number of advantages.  Most of the code I see here has
> ORGs in it, indicating that the assembly is in absolute mode.  I have NEVER
> yet used absolute mode.  The big advantage of using the linker is that code
> can be in separate modules.  This makes things much more maintainable and
> reusable.  Each module also gets its own namespace for local symbols, so you
> don't have to worry about name collision with some unrelated part of the
> code.  You can now group functional blocks into separate modules.  This also
> provides a natural place to document the interfaces between the functional
> blocks.
>
> Since the code is now a collection of relatively small modules, you can
> dictate that each module must be entirely on one page.  I do this by setting
> up a separate linker section for each code page.  Except for the code at the
> startup location and the interrupt routine, I just let the linker stick a
> module wherever it wants to.  It does this quite nicely based on a best fit
> algorithm.  I have never yet had a code module that was bigger than a page,
> or even close to it.  I have had data modules bigger and handled that by
> making separate one-off exceptions in the linker control file for that
> project.  I've only had to do that once in over two dozen PIC projects, and
> that happened to be a personal project.
>
> Now that the code within a module is all guaranteed to be on the same page,
> I use the convention that PCLATH is always pointing to that page.  It is the
> responsibility of the caller (or GOTOer) to set PCLATH to the new page.  I
> can forget about PCLATH when doing GOTOs and CALLs within a module.  To call
> a global routine in some other module, I use the GCALL marco.  This sets
> PCLATH before the call and restores it after.
>
> The GCALL and other macros are in STD.INS.ASPIC which can be found at
> http://www.embedinc.com/pic.  This page also describes a bunch of "standard"
> modules I use with most PIC projects and provides template modules where you
> can fill in the blanks to make your own PIC project.  These are the same
> template files I use when creating a new project.  Click on the "HAL example
> project" link to see the modules and source code for a real project.  You
> can see that the executable part of this project was broken into 9 separate
> modules.

>
> > Do you use your GCALL macro for every call from
> > the main routine to the modules??
>
> I use GCALL for every call between modules, whether its from the main
> routine or not.  However, I sometimes don't call event routines that handle
> events when they are detected by the main loop.  I usually use the
> convention that code for handling a specific event jumps back to LOOP_MAIN,
> which is the start of the event check loop.  This gives events a priority
> with the first checked the highest priority.  Since the main event loop
> doesn't need the general register preserved and since event handling
> routines don't need to return, I GOTO them instead of CALL them.  If they
> are external to the MAIN module, then use GJUMP (global jump, sets PCLATH
> before the GOTO).
>
> > I understand your
> > modules use local calls within themselves.
> > It would be nice if the linker were optimising,
> > and only inserted the minimum code for any call.
>
> Yes, but unfortunately it isn't.  This method does do unnecessary PCLATH
> diddling when calling between modules that happened to end up on the same
> page, but this is probably rather trivial from the overall system point of
> view.  If it were to ever be an issue, I would force the modules in question
> onto the same page with the CODE directive, then use a local call.  I would
> make a new locally defined macro for this, just to document the particular
> calls and to allow a way to get back to GCALL if things changed.
>
> > As many modules use the same shared (global) data
> > to manipulate it, do your modules use banksel on
> > every access of these variables?? Isn't that slow?
>
> No, yes.  I always define a global assembly constant called GBANK which is
> the register bank the ordinary global state is in.  You can see this
> declaration in the template QQQ.INS.ASPIC or in the example HAL.INS.ASPIC.
> The constant GBANKADR is automatically derived from GBANK, and is an address
> within the GBANK bank.  GBANKADR can be used with DBANKIF to set the bank
> for access to the global state.
>
> By convention, each module declares the local assembler constant LBANK and
> LBANKADR which is the bank and address within bank for local persistant
> state used privately by that module.  I don't like allocating state to
> particular banks at assembly time, but the advantage is that you know which
> bank it is in at assembly time and can therefore do clever things with that
> information, like the DBANKIF and related macros.  If the convention is
> followed, then it is easy to move local state of a module from one bank to
> another just by changing the LBANK value for the module.
>
> Note also that you're not stuck having just GBANK for global state.  You can
> make up your own names for other groups of state.  I've done this for I/O
> buffers and the like sometimes.  For example, BUFBANK and BUFBANKADR might
> be for the UART I/O FIFOs.
>
> ********************************************************************
> Olin Lathrop, embedded systems consultant in Littleton Massachusetts
> (978) 742-9014, olinspamBeGonespamBeGoneembedinc.com, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics