On 04/10/2011 15:59, Peter Bigot wrote: > 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
Technically, you are of course entirely correct. And even if the C standard /did/ mention stacks and heaps, that doesn't mean the compiler would actually have to use them - it is always free to choose a different implementation as long as it appears as though it follows the rules of C. However, the original question was from someone who knew very little about how memory is organised in C - I don't think it helps to talk about how it works on a poor-quality pseudo-C compiler for a very limited processor. Almost all C compilers, including mspgcc, organise their memory in the same way, so I think it is fair to consider that the "generic" answer and leave it there. (I can think of several other compiler/target combinations that differ at least slightly from this model - some of which are close enough to the standards to be worthy of the name "C compiler". But I don't think it will help the O/P.) On re-reading what I wrote, the tone of my reply was perhaps a bit crass, however - and for that I apologise. mvh., David > > >> >> 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 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
