> [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.