>
>Let's start with banking.  Most of the 14 bit banked PICs have global memory
>in the last 16 locations of each bank.  I find that reserving these mostly
>for temporary scratch values that get banged around a lot, and using banked
>memory for persistent state works well.  My REG0 - REG12 "general registers"
>are in this memory, and can therefore always be accesses without regard to
>the bank setting.  That, together with good modularization and
>semi-automation of bank setting with macros (see DBANKIF and related macros
>in STD.INS.ASPIC at http://www.embedinc.com) make banking quite manageable
>in my opinion.

In the AVR, you get this with 32 general registers, and a completely 
flat ram space.
You CAN dedicate registers as you desire, or not. Tables can start 
anywhere, and be as long as needed.
The penalty we pay is 16 bit instructions vs shorter instructions.
It's a plus for the chip maker if they can work in smaller widths, 
but that's really a non-issue for me the programmer.
Since the instructions execute in so few clock cycles (most 1 cycle, 
some 2 cycle) and I don't have to spend any time or effort on 
paging/banking issues, this is my personal favorite.


The Z8 takes this to the extreme, where ALL ram is registers, and any 
pair of registers can be a 16 bit pointer.
AFAIK, they still have some significant restrictions in RAM size 
though, because of this, and still have Clock/12 internal division.

Compromises.. Always you have to give up something somewhere.


IMHO, the actual advantages of paging/banking are minimal, and solely 
an internal machine thing.
The rest is ways to make you work with the banking, since you have no 
other choice in the pic line.

The tradeoffs of the internal machine issues show up in ways that are 
more difficult to compare, like price per 10,000 parts, code 
development time, HLL tool efficiency, and overall execution speed.

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist