doubt on regarding stacks

P

pmm

Hi all,
Plz dont fire at me if this is a silly question
Is there any way to know in which direction stack grows
pmm
 
R

Richard Bos

pmm said:
Is there any way to know in which direction stack grows

Not in ISO C. In fact, ISO C does not guarantee that you even _have_ a
stack as you understand that term.

Richard
 
D

dandelion

Richard Bos said:
Not in ISO C. In fact, ISO C does not guarantee that you even _have_ a
stack as you understand that term.

Correct, of course, but OTOH, you would have a pretty unusual platform if
you did not.

One filthy trick you could employ (with all warnings set abut
non-portability and compliance) is to
take the address of some local variable, call a function allocating another
local and take that address,too. Then a simple comparison of the addresses
would yield the direction in which the stack grows (assuming your compiler
does indeed have a stack and uses it).

However, that falls into the "Filthy Tricks" department and you no
guarantees whatsoever that it will indeed work on your target platform.

Usually consulting the documentation on your CPU/Compiler will yield more
reliable answers.
 
I

infobahn

pmm said:
Hi all,
Plz dont fire at me if this is a silly question
Is there any way to know in which direction stack grows

It grows in the direction of the most recently added item.
 
P

pmm

dandelion said:
Correct, of course, but OTOH, you would have a pretty unusual platform if
you did not.

One filthy trick you could employ (with all warnings set abut
non-portability and compliance) is to
take the address of some local variable, call a function allocating another
local and take that address,too. Then a simple comparison of the addresses
would yield the direction in which the stack grows (assuming your compiler
does indeed have a stack and uses it).

However, that falls into the "Filthy Tricks" department and you no
guarantees whatsoever that it will indeed work on your target platform.

Usually consulting the documentation on your CPU/Compiler will yield more
reliable answers.

Thanks for the reply
I sure did the above trick but I felt like a bad practice. I thought of
to have a better code so I posted into this group.

plz let me know the correct concepts. please recommend any web pages
deals with the above concepts
thanks a lot
 
D

dandelion

pmm said:
Thanks for the reply
I sure did the above trick but I felt like a bad practice.

It is.
I thought of to have a better code so I posted into this group.

plz let me know the correct concepts.

There are none.

Relying on the stack to grow this way or that is in itself bad practice and
will introduce heavy machine dependencies. You should not have to and in C
you do not need to.
 
C

Chris Dollin

pmm said:
Hi all,
Plz dont fire at me if this is a silly question
Is there any way to know in which direction stack grows

Not portably.

Why do you think you need to know?
 
K

Kiru Sengal

pmm said:
Hi all,
Plz dont fire at me if this is a silly question
Is there any way to know in which direction stack grows
pmm

Simple, research your compiler/OS/hardware.
The "addresses (in C)" of local variables 'might' give you an answer,
but nothing in the standard stops an implementation from mapping C
local variable addresses in a different order than what's actually
occuring at the hardware level.
 
E

E. Robert Tisdale

pmm said:
Is there any way to know
in which direction stack grows?

A stack always grows upward. Unfortunately,
neither your computer nor your compiler knows up from down.
The C programming language doesn't know anything about stacks.
It only knows about "automatic storage"
which is usually implemented on the program stack.
For the typical implementation,
you can think of program memory being organized
as a contiguous sequence of [virtual] memory addresses
starting with 00000000 at the top and
ending with FFFFFFFF at the bottom.
The bottom of the program stack
is somewhere near the bottom of [virtual] memory
and grows upward into free storage.
The "stack pointer" is
"decremented" when you "push" objects onto the program stack and
"incremented" when you "pop" objects off of the program stack.
 
K

Keith Thompson

E. Robert Tisdale said:
pmm said:
Is there any way to know in which direction stack grows?

A stack always grows upward. Unfortunately,
neither your computer nor your compiler knows up from down.
The C programming language doesn't know anything about stacks.
It only knows about "automatic storage"
which is usually implemented on the program stack.
For the typical implementation,
you can think of program memory being organized
as a contiguous sequence of [virtual] memory addresses
starting with 00000000 at the top and
ending with FFFFFFFF at the bottom.
The bottom of the program stack
is somewhere near the bottom of [virtual] memory
and grows upward into free storage.
The "stack pointer" is
"decremented" when you "push" objects onto the program stack and
"incremented" when you "pop" objects off of the program stack.

This description assumes that the stack grows toward low addresses
(when the addresses are interpreted as integers). (It also assumes
32-bit addresses.) It's entirely possible for the stack to grow
toward high addresses. I don't know how common this is in real-world
systems -- and since I don't program in assembly or machine language,
I don't need to know. If I did know, there would be no way to use
that knowledge in a portable program; it's unlikely it would be useful
even in a non-portable program.

If you're curious about how some particular system does this, here's a
program that *might* be helpful:

#include <stdio.h>

void func(int *outer_addr)
{
int inner_obj;
printf("Object in main() is at [%p]\n", (void*)outer_addr);
printf("Object in func() is at [%p]\n", (void*)&inner_obj);
#ifdef ALLOW_UNDEFINED_BEHAVIOR
if (&inner_obj > outer_addr) {
printf("Stack appears to grow toward high addresses\n");
}
else {
printf("Stack appears to grow toward low addresses\n");
}
#endif
}

int main(void)
{
int outer_obj;
func(&outer_obj);
return 0;
}

Since inner_obj is "higher" on the stack than outer_obj, examining
their relative addresses can tell you which way the stack grows *if*
that's a meaningful question in the first place. On many systems,
printf's "%p" format will show you a numerically meaningful
representation of a pointer; if so, you can compare them by examining
the output.

Using the "<" operator to compare two pointers that don't point into
the same object (or just past the end of it) invokes undefined
behavior. It can legally return a value that depends on the phase of
the moon, or it can crash your entire system. On many systems, such a
comparison does give a result that's meaningful for the underlying
system (though not necessarily meaningful in C terms). On such
systems, the above program with the macro ALLOW_UNDEFINED_BEHAVIOR
defined will probably tell you which way the stack grows.

Keep in mind that there's really nothing meaningful you can do with
this information, though of course there's nothing wrong with wanting
to satisfy idle curiosity.

"Which way does the stack grow" is actually an excellent question, but
knowing the answer isn't nearly as useful as knowing why there's not
really any meaningful answer.
 
N

Nils Weller

(I think you really meant to say that it usually grows ``downward.'')

[...]
This description assumes that the stack grows toward low addresses
(when the addresses are interpreted as integers). (It also assumes
32-bit addresses.) It's entirely possible for the stack to grow
toward high addresses. I don't know how common this is in real-world
systems -- and since I don't program in assembly or machine language,
I don't need to know.

I happen to remember that the stack usually ``grows upward'' on
PA-RISC hardware. At least this is the case for HP-UX and Linux systems
(but applications running on HP-UX on Itanium have a downward growing
stack as well, and of course so do those that run on most (all?)
non-PA-RISC Linux hardware.)
 
N

Neil Kurzman

E. Robert Tisdale said:
pmm said:
Is there any way to know
in which direction stack grows?

A stack always grows upward. Unfortunately,
neither your computer nor your compiler knows up from down.
The C programming language doesn't know anything about stacks.
It only knows about "automatic storage"
which is usually implemented on the program stack.
For the typical implementation,
you can think of program memory being organized
as a contiguous sequence of [virtual] memory addresses
starting with 00000000 at the top and
ending with FFFFFFFF at the bottom.
The bottom of the program stack
is somewhere near the bottom of [virtual] memory
and grows upward into free storage.
The "stack pointer" is
"decremented" when you "push" objects onto the program stack and
"incremented" when you "pop" objects off of the program stack.

The Hardware stack may inc or dec the memory address on a Push.
C does not care, It does not require a stack.
That Said most compilers use the HW stack, and most go the same way.
 
E

E. Robert Tisdale

Neil said:
The Hardware stack may inc or dec the memory address on a Push.
C does not care, It does not require a stack.
That Said most compilers use the HW stack, and most go the same way.

Please clarify what you mean by "HW stack".
My Intel Pentium floating-point stack
is implemented as a *push-down store*.
It doesn't have a hardware program stack.
One general purpose register is designated as the "stack pointer"
and there are *assembler* instruction to push an pop this stack
but they simply move data onto or off of the program stack
and "decrement" or "increment" the stack pointer respectively.

C does not require a [program] stack but,
in fact, every viable ANSI/ISO standard compliant compiler
uses the program stack to manage automatic storage.
 
P

pmm

Dear Mr Keith Thompson
I was just curious as you have guessed and thanks you very much for
replying and making me to learn few more things
thanks again
bye
PMM
 
D

DHOLLINGSWORTH2

pmm said:
Thanks for the reply
I sure did the above trick but I felt like a bad practice. I thought of
to have a better code so I posted into this group.

plz let me know the correct concepts. please recommend any web pages
deals with the above concepts
thanks a lot

The correct method is to write to the hardware manufacturer, and request the
data sheets for the proccessor your working with. ( don't hesitate to get
the info from the horses mouth.)
I can just about bet you that it grows away from the base: )
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,159
Messages
2,570,881
Members
47,418
Latest member
NoellaXku

Latest Threads

Top