468,761 Members | 1,751 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,761 developers. It's quick & easy.

doubt on regarding stacks

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

Nov 14 '05 #1
18 1381
"pmm" <mu************@hotmail.com> wrote:
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
Nov 14 '05 #2

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:42***************@news.individual.net...
"pmm" <mu************@hotmail.com> wrote:
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.


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.
Nov 14 '05 #3
pmm

dandelion wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:42***************@news.individual.net...
"pmm" <mu************@hotmail.com> wrote:
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.


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

Nov 14 '05 #4
pmm wrote:

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.
Nov 14 '05 #5
pmm
Thanks for the reply
your answer is very informative

Nov 14 '05 #6

"pmm" <mu************@hotmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

dandelion wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:42***************@news.individual.net...
"pmm" <mu************@hotmail.com> wrote:

> 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.
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.


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.
Nov 14 '05 #7
pmm wrote:
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?

--
Chris "electric hedgehog" Dollin
Nov 14 '05 #8
pmm wrote:
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.

Nov 14 '05 #9
pmm wrote:
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.
Nov 14 '05 #10
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
pmm wrote:
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.

--
Keith Thompson (The_Other_Keith) 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.
Nov 14 '05 #11
In article <ln************@nuthaus.mib.org>, Keith Thompson wrote:
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
pmm wrote:
Is there any way to know in which direction stack grows?
A stack always grows upward. Unfortunately,


(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.)

--
My real email address is ``nils<at>gnulinux<dot>nl''
Nov 14 '05 #12


dandelion wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:42***************@news.individual.net...
"pmm" <mu************@hotmail.com> wrote:
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.


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


many 8bitters the PIC and 8051 for example.


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.


Nov 14 '05 #13


"E. Robert Tisdale" wrote:
pmm wrote:
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.
Nov 14 '05 #14
Neil Kurzman wrote:
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.
Nov 14 '05 #15
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

Nov 14 '05 #16
pmm
just curious
:-)

Nov 14 '05 #17
pmm wrote:

just curious
:-)


About what?

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #18

"pmm" <mu************@hotmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

dandelion wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:42***************@news.individual.net...
> "pmm" <mu************@hotmail.com> wrote:
>
> > 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.


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


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: )
Nov 14 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by praba kar | last post: by
6 posts views Thread by praba kar | last post: by
1 post views Thread by praba kar | last post: by
3 posts views Thread by darkstorm | last post: by
4 posts views Thread by SandyIsCool | last post: by
8 posts views Thread by somenath | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.