Eugene Rosenzweig wrote:
>
> > The 16 series stack issue is really just one of perception.
> > The only thing you
> > really need to access the hardware stack for is to switch tasks when
> > pre-emptively multitasking.
>
> [ snip a discussion of multitasking and variable passing on stack ]
>
> > Regards
> > Sergio Masci
>
> I would have thought the most basic problem with preset stack is inability
> to descent deeper into subroutine calls than the size of the stack. Nothing
> 'perceived' about that that, it's a hard limit.

Hi Eugene,

From my point of view, I do not see the hardware stack as a limiting factor to
calling subroutines. My xcsb compiler allows function calls to greater than 8
levels (the limit is dependent on available RAM). It is very easy to do the same
thing in assembler. The only annoyance is having to work out what the current
level of the static stack is. This is where a compiler comes in handy, it keep
track for you.

You see it one way, I see it another, so yes it is perceived.

> It is by no means a terrible
> problem since the program memory size of 16 series is rather small and the
> chip is not designed to run general purpose software so there is no much
> need for deep call stack or recursion or general multitasking.
>
> It is when the size of the program memory increases it becomes feasible to
> implement more complex software and then the inability to manipulate the
> stack would prove more of a problem.

But the reason I really like PICs is because I can glue a bunch together and
have each do its own job without worrying about the complexities of a big fast
single processor trying to do everything simultaniously.

>
> Eugene.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optiming structured PIC BASIC compiler

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body