How the stack grows

[deepak]

Hi All,

In C I heard the stack grows from top to bottom and heap from bottom to
top.
Is it compiler depend?

[Richard Heathfield]

deepak said:

>
Hi All,

In C I heard the stack grows from top to bottom and heap from bottom to
top.
Is it compiler depend?

C doesn't require the compiler to use a stack. If the compiler /does/ use a
stack, what kind of stack it uses is entirely up to it. It needn't even
grow from top to bottom or bottom to top (for example, it may be
implemented as a linked list of dynamically allocated stack frames with
arbitrary addresses).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Tim Prince]

deepak wrote:

Hi All,

In C I heard the stack grows from top to bottom and heap from bottom to
top.
Is it compiler depend?

If you look at gcc source, you should find how it investigates whether
there is an apparent stack, and which way it grows. Presumably, that
code is doing things outside standard C. gcc accepts the system
employed by the bootstrap compiler. A successful gcc build shows you
already that more than one compiler can share the same scheme (the one
implemented by the hardware/OS).

[Richard Bos]

Tim Prince <tp*****@nospam computer.orgwro te:

deepak wrote:

In C I heard the stack grows from top to bottom and heap from bottom to
top. Is it compiler depend?

If you look at gcc source, you should find how it investigates whether
there is an apparent stack, and which way it grows. Presumably, that
code is doing things outside standard C. gcc accepts the system
employed by the bootstrap compiler. A successful gcc build shows you
already that more than one compiler can share the same scheme (the one
implemented by the hardware/OS).

And also, conversely, that one compiler can work with different schemes.

Richard

[David T. Ashley]

"deepak" <de*********@gm ail.comwrote in message
news:11******** *************@q 2g2000cwa.googl egroups.com...

>
Hi All,

In C I heard the stack grows from top to bottom and heap from bottom to
top.
Is it compiler depend?

In the early days of the PC when 640K was the rule, this may have been the
case. I'm not sure it is the case today.

The direction the stack grows is going to be architecture-dependent. All
machines have a certain direction the stack pointer goes on a subroutine
call and instructions like PUSH, and typically a 'C' compiler will build
stack frames starting with this convention.

The heap may also be OS-dependent. In the old days, a program had nearly
the whole machine memory to itself, and it would start the stack and heap at
opposite ends of free memory and maximize the time until they collided.
These days when OSs are more sophisticated and there is memory management
hardware in place, I doubt it is done this way.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Walter Roberson]

In article <5o************ *************** ***@giganews.co m>,
David T. Ashley <dt*@e3ft.comwr ote:

>The direction the stack grows is going to be architecture-dependent.

True.

>All
machines have a certain direction the stack pointer goes on a subroutine
call and instructions like PUSH, and typically a 'C' compiler will build
stack frames starting with this convention.

Not necessarily true. On some processors, the direction might just
be a matter of convention, and one OS might support different ABI
(Application Binary Interfaces) that use different conventions.
There are machines for which the "preferred" direction is controlled
by a CPU status register, alterable by the kernel.

Some machines do not have "PUSH" or "CALL" instructions with
built-in directions: they might instead just have "autoincrem ent"
and "autodecrem ent" addressing modes, and a PUSH might be
something like MOV.L 3248(R11), -(R7) where R7 as stack pointer
is just an ABI convention and where (R7)+ could be used by an ABI
instead to grow the stack in the other direction.

C compilers for such machines follow the OS ABI conventions, rather
than being forced into one direction or another according to some
hardware architecture limitation.

>The heap may also be OS-dependent. In the old days, a program had nearly
the whole machine memory to itself, and it would start the stack and heap at
opposite ends of free memory and maximize the time until they collided.
These days when OSs are more sophisticated and there is memory management
hardware in place, I doubt it is done this way.

It is still often done more or less that way, but these days you
have to worry about where the shared libraries or DLLs are going to
pop up in your address space, and have to worry about where any shared
memory segments will appear. On some systems, large heap allocations might
get turned into shared memory segment allocations (making it easy to
release the entire block back to the OS when the process free()'s it...
something that has been traditionally hard to do.)
--
Programming is what happens while you're busy making other plans.

[Keith Thompson]

"David T. Ashley" <dt*@e3ft.comwr ites:

"deepak" <de*********@gm ail.comwrote in message
news:11******** *************@q 2g2000cwa.googl egroups.com...

>In C I heard the stack grows from top to bottom and heap from bottom to
top.
Is it compiler depend?

In the early days of the PC when 640K was the rule, this may have been the
case. I'm not sure it is the case today.

[...]

Even in "the early days of the PC when 640K was the rule", there were
plenty of C implementations for systems other than PCs.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Peter Nilsson]

deepak wrote:

In C I heard the stack grows from top to bottom and heap from bottom to
top.
Is it compiler depend?

It depends on the escutcheon grommets.

--
Peter

[Richard Tobin]

In article <5o************ *************** ***@giganews.co m>,
David T. Ashley <dt*@e3ft.comwr ote:

>In C I heard the stack grows from top to bottom and heap from bottom to
top.
Is it compiler depend?

>In the early days of the PC when 640K was the rule, this may have been the
case. I'm not sure it is the case today.

When talking about C, a more natural computer to consider is the PDP-11.
PCs were latecomers to the C party.

And interestingly, the PDP-11 is an example of a machine where stacks
can be easily used in either direction. Rather than a "push"
instruction, it has auto-increment and auto-decrement modes for
register access.

Even on such a machine, there are typically good reasons to use a
particular direction for the call stack. One is compatibility
with other languages on the same system, and another is that the
hardware may assume a particular stack direction when generating
interrupts, though I think it's rare for hardware interrupts to use
the user stack these days.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Gordon Burditt]

>In C I heard the stack grows from top to bottom and heap from bottom to

>top.

C doesn't define anything called a "top" or "bottom" of memory.
Typically the "top" is the memory address closest to the top of the
page on a memory diagram written on a piece of paper. That usually
has little to do with the machine involved and more to do with the
person who drew the diagram.

>Is it compiler depend?

C doesn't define anything called a "stack" or "heap", either, and
there's no guarantee that these are mutually exclusive.