On 30/09/2011 02:23, Sergio Campamá wrote:
> Thanks for the info Eric! I think I can manage with this to get more
> info out of google. :)
>
Imagine a cafeteria. Dinner plates are kept in a spring-loaded trolley,
so that the top plate is always easily available. New clean plates are
put on top, pushing the stack down. When you need a plate, you take one
off the top, and the rest goes up a little. That's your stack - grows
as big or small as needed, but you only make use of the top few parts.
(A locally declared VLA is just a pile of plates whose size you don't
know in advance.)
Then there's the shelves and cupboards, all neatly labelled with
everything in its place. You always know exactly where to find things,
and put them back in the right place afterwards. That's your static memory.
Then there's the storeroom with stuff jumbled in randomly. When you
want to store something new, it might take you time to find a space - or
you might not find a space at all. You spend a lot of your time cursing
and wishing someone could tidy it up and sort the free space into one
big space. That's your heap, which you generally want to avoid using.
mvh.,
David
>
>
>
>
> 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 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
