stack vs. heap

"falcon" <shahbazc@gmail.com>
15 Oct 2005 12:59:22 -0400

          From comp.compilers

Related articles
stack vs. heap shahbazc@gmail.com (falcon) (2005-10-15)
Re: stack vs. heap cjc1@ucs.cam.ac.uk (Chris Cheney) (2005-10-19)
Re: stack vs. heap thant@acm.org (Thant Tessman) (2005-10-19)
RE:stack vs. heap jatin.bhateja@amdocs.com (Jatin Bhateja) (2005-10-20)
| List of all articles for this month |
From: "falcon" <shahbazc@gmail.com>
Newsgroups: comp.compilers
Date: 15 Oct 2005 12:59:22 -0400
Organization: http://groups.google.com
Keywords: storage, question
Posted-Date: 15 Oct 2005 12:59:22 EDT

This is sort of a silly question but I never took a compiler class and
every text I read assumes that reader will understand the difference
between stack space a heap. Now stack and heap are spoken of as if
they are two completely different locations in a computer...so much so
that I'm starting to question my assumption that stack and heap are
both locations in memory. Heap space being of dynamic length and
stack size being known at compile time.


I remember reading that items in stack space can be manipulated much
faster than those on the heap...that part doesn't make sense to me. Any
clarifications? Thanks.


Falcon
[They're both memory, but they're different parts of memory. Stack
space is quick to allocate and free since it merely involves
increasing or decreasing the stack and perhaps frame pointer. Heap
space requires something along the lines of Unix malloc() to track
what's allocated and what's available. References to stack space may
be slightly faster than to heap since stack references are invariably
relative to a stack pointer register, but heap addresses have to be
loaded from storage into a register before they can be used to
reference the allocated memory. If you look at the generated
assembler code for a few little routines in your favorite language,
that can help clarify what's going on. -John]





Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.