Harumph. I'm not sure where to point you. I learned about this stuff in
basic computer science classes and/or on the fly.
The major question is where to data variables live....
1st there is registers (clearly local scope)
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.
Another area of memory is static data. There are globals that are
initilized (called the .data section) and globals that are uniitilized
(.bss, historical name from an old IBM assembler). This is where the
globals that your program defines live. On start up, the .data section is
initliized and .bss is zero'd.
Now the there is the rest of memory. What ever is left over. Typically,
the remainder of memory is made into the heap. See
Heap_Memory<http://en.wikipedia.org/wiki/Heap_memory>.
For various reasons, using heap and dynamic memory on an embedded system
is not a great idea.
Hope that helps.
eric
On Thu, Sep 29, 2011 at 4:36 PM, Sergio Campamá <scamp...@ing.puc.cl> wrote:
> Thanks! But is there any more? I'm not a computer scientist, just an
> electrical engineer who learnt how to program tutorial-style. I really don't
> know what heap or stack memory is. And wikipedia isn't very helpful. Do you
> know of any book that explains this matters?
>
> Thanks!
> ---------------------------------------
> Sergio Campamá
> sergiocamp...@gmail.com
>
>
>
>
> On Sep 29, 2011, at 6:25 PM, David Brown wrote:
>
> > On 29/09/11 21:00, Sergio Campamá wrote:
> >> On Thu, Sep 29, 2011 at 3:55 PM, David
> >> Brown<david.br...@hesbynett.no>wrote:
> >>
> >>> On 29/09/11 20:52, Sergio Campamá wrote:
> >>>> Hello,
> >>>>
> >>>> I was under the impression that in C you could not do something
> >>>> like:
> >>>>
> >>>> void func(int size) { int array[size]; //something return; }
> >>>>
> >>>> But a friend of mine just proved me wrong, using mspgcc...
> >>>> Searching around we found this to be VLA (variable length array)
> >>>> Does this kind of usage fall into dynamic memory? My impression
> >>>> is that the answer is yes, and therefore it shouldn't be used on
> >>>> microprocessors, because malloc can cause havoc (as someone told
> >>>> me some emails ago in this very same group).
> >>>>
> >>>> What are your thoughts on VLA? Does it use malloc internally, and
> >>>> therefore should be avoided?
> >>>>
> >>>
> >>> Variable length arrays are like any other data - they can go in
> >>> various places. In a case like this, you have defined a non-static
> >>> local variable - just like any other non-static local variable, it
> >>> goes on the stack. So as long as you are careful not to overflow
> >>> your stack, this should be fine - it doesn't suffer from the risks
> >>> you get with malloc (or, more accurately, the risks you get with
> >>> free), namely unpredictably long delays, fragmented heaps, and no
> >>> space errors.
> >>>
> >> Thanks David. I have been meaning to understand fully well how
> >> memory works in terms of stack and ram. Is there any text or
> >> resource available that could help me understand that?
> >>
> >
> > It's basic C. Anything defined with a static lifetime (global data,
> > static local data) is statically allocated at fixed memory addresses.
> > Anything local to a function is either kept in registers (or removed
> > altogether by the optimiser) or put on the stack. Anything allocated by
> > malloc (or standard "new" in C++) goes on the heap.
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
