Hi John!

> While there are certainly exceptions to any rule, most programs that need
> a lot of RAM need it for arrays or other such constructs.  Given that any
> array access has some associated setup work anyhow, having to deal with

I agree, but those constructs can be plenty and small, instead of one
or two big ones.

> array banks isn't a big deal.  For simple variables, however, it's nice to
> simply *ignore* bank-switching and related concepts.  If 96 bytes' worth
> of registers are non-banked, then the vast majority of applications--even
> those which use up hundreds of bytes worth of arrays--will be able to
> handle all their non-array needs without bank-switching.

I was thinking of the following. Lets say you have a set of routines that
handle some sort of calculations that use an array. Would you put the
array and the other variables in the same page or not? You don't want to
limit its use to a single project, maybe you'll first use it in a small
program but later reuse it for a large one. If you switched banks the
first time it would be a waste of code and efficency, if you modified it
for the second program you would be forced to play with code you've
programmed some time ago, and if you consider both options from a start
you would have to work more.

I'd rather try to use not more than one bank for a component's
variables, minimizing bank-switching inside the component, and leave the
bank-switching for the interface between them. I find it easier to
plan a efficent organization if you work that way. And if RAM pages are
large this is easier to do. I don't mean to say that 224 vs. 128 bytes is
very much important, but, on the other side, would it be that handy to
have a large common area?

> Further, even for programs that do need large arrays [bigger than 128
> bytes] the overhead of selecting the appropriate 128-byte page is really
> not severe.  In fact, with arrays that span pages it's probably easier to
> deal with 128-byte pages (power of two) than 224-byte pages (not a power
> of two).  For example, suppose ArrayH:ArrayL is a two-byte pointer to a
> ...............

Ok, I'll put that on the scale too, but I still think the best choice is
not clear. I mean, how many times will you need an array that takes almost
all of the memory, not being able to spare ten or so extra machine-cycles
to access it, nor program it's client in such a way as to use a pair of
bank and offset pointers? Can't think of many, but I can think of a lot of
times when I'll be organizing a program working much more comfortably
because I have larger pages.

> I agree that a "nice" implementation (like a BANKFSR register) would
> probably have added a little silicon; IMHO the benefits from being able to
> truly bank the IND's would probably be worth it.  Certainly, though,
> while we can debate about the exact best size for the banked/unbanked
> split I hope you will agree with me that there oughta be more than SIX
> unbanked registers?

I may be, as I told you I haven't programmed the 17CXX family and I've
no experience on unbanked regs. But yeah, it sounds as if six were too
few, perhaps they could have added another bit and put sixteen more, but
before criticizing this I'd like to see more clearly what the real
drawbacks of scarce unbanked regs are.

> ...
> those which improve programmer convenience without much cost whatsoever.
> I think placing the bank split in a better place would have fallen in the
> latter category.  My choice of 128 was intended both as a compromise
> ....

I agree, I'm just not sure if having many more unbanked regs results in
improved programmer convenience.

Regards,

Andres Djordjalian
adjordj@aleph.fi.uba.ar