Thanks for the info Eric! I think I can manage with this to get more info out
of google. :)
Best regards,
---------------------------------------
Sergio Campamá
sergiocamp...@gmail.com
On Sep 29, 2011, at 9:11 PM, Eric Decker wrote:
>
> 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. 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
