On Tue, Oct 4, 2011 at 8:23 AM, David Brown <da...@westcontrol.com> wrote:
> On 04/10/2011 13:07, JMGross wrote:
> >
> > Eric, did you ever program the Microchip PIC series?
> > They used to have (don't know about the current ones) a hardware stack.
> > All local variables had to go to a fixed memory location too, recursions
> were forbidden.
> > (actually local variables were handled like static ones but initialized
> on function start)
> > Still the programming language was C. (not really ++)
> > Well, the PICs were no real processors but rather programmable interrupt
> controllers
> > (hence the name). And I'm really happy we moved from PIC to MSP before I
> > entered teh scene. I had to do maintenance on some of the PIC projects
> > (and to migrate some to MSP) and I'm happy I hadn't to deal with a pIC
> > for years now.
> >
> > But it shows that there is no generic answer to where variables live.
> > It really (as you said) depends on the processor and the compiler.
> >
>
> There /is/ a generic answer for C, as has been given in this thread.
>
> The PICs (well, PIC14 and PIC16 anyway) are brain-dead processors, the
> compilers that Microchip sells for them don't come close to standard C.
>
> In C, local variables go on the stack, or in registers, or are
> "optimised away" by the compiler. Statically (i.e., compile and
> link-time) allocated data goes in fixed memory spaces. Dynamic data
> allocated with malloc goes on the heap.
>
The words "stack" and "heap" do not appear in the C standard. There is only
static and automatic storage duration. The mechanism by which the storage
duration requirements are met is left to the implementation. None of stacks,
heaps, or registers are required to implement C, though they are currently
the most common solutions to those requirements and are how it is done with
mspgcc on the MSP430. JM's answer is relevant for somebody who could
encounter more unusual architectures.
Peter
>
> If you are masochistic enough to choose a small PIC, don't con yourself
> into thinking you are programming with C. You are using a limited
> C-like language, and need to understand how it works and its limitations
> to get the best from it. It might be good enough for the job in hand -
> it may even be the best choice, all things considered. But limitations
> of Microchip's tools do not affect generic answers about C and C compilers.
>
> (PIC initially referred to "Peripheral Interface Controller", which is
> totally different from a programmable interrupt controller.)
>
> mvh.,
>
> David
>
>
>
>
>
> > JMGross
> >
> > ----- Ursprüngliche Nachricht -----
> > Von: Eric Decker
> > An: Sergio Campamá
> > Gesendet am: 30 Sep 2011 02:11:40
> >
> > next up is the stack. This depends on the architecture of the
> underlying
> > machine but some sort of stack is usually implemented and the compiler
> knows
> > how take advantage of these things. The compiler uses the stack for
> saving
> > registers on entry to a routine and restore on exit. It also uses the
> stack
> > for allocating space for local variables. A stack typically is a LIFO
> > (last in first out) queuing structure.
> >
> > But where does the stack live... When a program first boots up (assuming
> an
> > embedded system), one of the things that happens is the stack pointer is
> > set. A region of memory is set aside for the stack and the stack pointer
> is
> > set to the top of the stack area and grows downwards as things are pushed
> on
> > to the stack. All of these of course depends on how the stack and the
> cpu
> > is implemented.
> >
> >
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
