>> A C compiler using a compiled stack looks at the size of the local
>> variables a function uses, allocates the appropriate amount of RAM
>> from a global buffer, and uses this RAM for the local variables.
>
> That means the local variables are unlikely to be in unbanked memory where
> accesses to them are really simple.

But the compiler can optimize variable location pretty well, and most 
compilers allow you to explicitly allocate globals in specific banks if you 
want to.

>> This
>> doesn't have the code space overhead of pushing and popping described
>> above.

> But it does have the additional code space overhead of bank switching 
> before
> local variable accesses.

Again, I don't think this is very heavy.

>> Nor does it have the (I presume) debugging nightmare of
>> declaring the wrong number of local variable bytes to the assembler,
>> or forgetting to push and/or pop.

> That sort of bug happens very rarely.

With your macro set I believe that implicitly.

>> The C compiler will also analyze the function call tree so that
>> functions which call other functions can share space in the local
>> variable pool without corruption.  For example, if func1 calls func2,
>> and each uses two bytes of local variables, the compiler will assign
>> bytes 0 and 1 to func1 and bytes 2 and 3 to func2.  But if func1 and
>> func2 are mutually exclusive, both will use bytes 0 and 1.  Thus the
>> compiler will only allocate the necessary number of bytes for local
>> variables, not requiring the (I presume) fixed-size buffer required in
>> the approach described above.

> But the compiler is forced to make pessimistic assumptions about the call
> depth and what local variables can be overlapped.  A stack does this
> automatically at run time.  The only issue becomes how much stack space to
> allocate.

Actually, the compiler can be _very_ smart about this. It knows the call 
tree and can set up memory location usage to minimize 'stack' depth 
(although dynamic issues generally are not resolved (ie: functions A and B 
both call function C and C calls D, but only when called by A, but not B).

> Each method has its pros and cons.  I don't think you can say up front 
> that
> one is inherently better for an arbitrary application.

As usual, the compiler makes life simpler for you. Sometimes that is _not_ 
what you want.

Bob Ammerman
RAm Systems

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