Alan B. Pearce wrote:

> >Agree fully. The GNU toolchain is supererb. Also, you know the
> >toolchain from other work (if you used it, that is work on Linux).
> >But the price for Atmel chips are a bit high so I often ends up
> >with a PIC micro in my designs anyway. Atmel has been a bit nicer
> >with samples latly but not as good as Microchip. But in most other
> >aspects they are the same. Its easy to work with both. I tend to
> >favor an AVR when I code in C and a PIC when I code in assembler.
> >
> >>If you really want to know the power of AVR, it's the availability
> >>of free C compilers, and the stack.  Instead of having a hardware
> >>based stack, with a preset depth, you're limited only by your memory
> >>availability.  These chips are extremely nice to program in.  ASM, or C.
>
> Is the stack issue still an issue with the 18F series? The impression I have
> is that it is possible to have a larger stack, but then I haven't studied
> them that much yet to actually try it. Then with the various compilers
> available for the 18 series the architecture differences between the two
> makes would more or less vanish.

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. People argue that you need to be able to pop return
addresses off the stack under certain conditions. No you don't need the ability
to do this, it's a hack which sooner or later bites you in the arse. People
argue that you can't push function arguments onto the stack or use it for local
storage or return results on it. The fact is that using a real stack to do any
of these things actually incurs very real runtime penalties - both speed and
program size. People argue that using a stack improves memory use, RAM that is
used by one functions can be reused by another function. This is true but there
is very little reason why the stack should be dynamic and all the burden of
using it be placed on the processor at run time (the number of instructions
needed to access variables on a dynamic stack is greater than to access global
static variables). The stack could be built at compile time, variables assigned
to their positions within this static stack (never changing) and accessed at
runtime without stack overheads. If you analyse the program properly it is
possible to determine where to locate local variables efficiently so that they
share the RAM and do not clash. Using a static stack does lose the ability to
write recursive functions but many people would argue that the need for this is
rare anyway and it is always better to use iteration anyway. You also lose the
ability to write re-entrant functions. Functions that can be used both in the
main line and an interrupt handler. It is rare that you need to be able to use a
function in this way and it is actually very easy to circumvent this problem
without resorting to dynamic stacks. Ok so the only real problem is the ability
to do pre-emptively multitasking, but how many people would even consider using
pre-emptively multitasking on such a small device. Cooperative multitasking is
far easier to use on such a device and does not require access to the hardware
stack.

Ok, so before you dismiss me as a raving loony, consider this, the xcsb compiler
generates code that uses a static stack and the code it generates is very fast
and efficient.

Regards
Sergio Masci

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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.