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. 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
