blunn@KEYCORP.COM.AU wrote:

>      Tom, you're not reading Byron's original message thoroughly.
>
>      Note the words 'easily' and 'typical'.
>
>      Byron is NOT saying that an addressable stack is MANDATORY.
>
>      He is saying that an addressable stack is a convenient means
>      for efficiently implementing a context switch.  Context switching
>
>      can be used to implement multi-tasking, which can in turn be used
>
>      to provide real-time behaviour.

Actually, I did read it carefully. What is missing is some of my
context, specifically my feel for just how much of this type of
discussion is dominated by past practice. In today's world of
microprocessors, in which experience is dominated by CISC parts with
stacks and register sets of various utility, there is a bias toward that
model in designing or even discussing system level constructs. (And
please lets not get off on a rant over CISC/RISC [which PIC's aren't]
stuff; it just doesn't fit here, OK?)

My problem is that when I set out to do almost any reasonable job with a
PIC processor I don't run into any problem with the underlying
architecture. I suspect (jeese, I'm modest - I actually know from years
of experience) that the first organizational steps I take when planning
a project are not in the same space as many other designers. I've spent
quite a bit of time with peers and not-so-peers (like my kids and their
friends) trying to pry back the edge of their perception in this exact
area.

I spent some time thinking about this last night; my conclusion is that
several of the designs I've done could have been done with standard
pre-emptive programming tricks, but I did them some other way, for the
same effect. I used to think I was being perpetually tricky, but
gradually I've come to see the invention of a clever trick as just
another part of the programming process. I've never seen a programmer
that didn't end up with a bag of tricks (or quit, but that's another
thing). So I end up supposing that some of what I might do on a 68000
with pSOS I do on a PIC in a different way, using some real time
programming constructs and, obviously, not any that can't be done.

The point is that I don't feel limited, even though I feel pretty good
about using (or even writing when necessary) real time tools. I don't
feel at all constrained by the PIC architecture. And, gosh, I tend to do
mostly real-timish stuff with these little guys: the first design I did
put 3 rs232 receive channels, 1 transmit channel, and a AD7710 serial
i/o interface on a 16MHz '71. All this stuff was running asynchronously,
and we really didn't have any problems, although we were maybe the first
to inform a Microchip FAE that the data sheet context swap example
forgot status and that they needed to do some weird nibble swapping to
get it right. (And, Andy - we did it with no ICE.)

All that's the reason I suggested that people actually describe some
stuff they're trying to do. If we can all see a clear problem that needs
an addressable stack to solve, then I'll be the first to admit it
(promise). If we can get suggestions from the group that implement the
design objectives without needing it (the stack) then we'll all have
learned something.

Or, we could just talk about it, and still maybe learn something.

--Tom Rogers