> What I feel falls short about this sort of masking - and it doesn't make
> any matter whether you AND or XOR - is that there's no checking at all
> that the correct page is selected.  Aside from its value as an eyecatcher
> that says "here's a page 1 address, dude," all this does is make sure you
> "know" which page a particular register is on.  Now, getting even that
> limited visibility of the register's page into the code is a good thing,
> but I've found that an imperfect, rather cumbersome macro package that
> provides a more dynamic check is worth its weight in gold.  I can see ways
> to make it even better, but I'm about at the limit of what I feel is
> practical for the rather weak macro language of MPASM (1), and this would
> all be a lot easier to implement from inside the assembler.  Or maybe not,
> depending on how bad its internal structure has become after years of
> incremental modification.  :-(

What I'd like to see would be the following:

[1] Since labels are probably going to be handled by the assembler as 16-bit
    values even though the PIC only uses at most the bottom 9 (and I don't
    think any 16Cxx's use anything more than the bottom 8), what I'd like
    to see would be something like this:

    00- 7F : Page 0 addresses
    80- FF : Page 1 addresses
   100-17F : Shared addresses [same in both pages]

    Thus, on a PIC16C84, the RAM would go from $10C to $12F; on a 16C622, it
    would go from [I think] $20 to $FF and $A0 to $E0.

[2] The ability to specify what the RP flag should be assumed to be in a
    range of code.

[3] The ability to specify what should be dome with the RP flag if it's
    "wrong" [error, change/do instruction/change back, or change/do
    instruction/keep changed until an instruction that needs it back, or
    until a "goto", "call", or label is encountered].

PS--On the 16C620/16C621, how should one save registers in an ISR since
    there's no address available in both banks for storing them?