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

[Richard Bos]

Re: doubt on regarding stacks

"pmm" <muralipmanohar @hotmail.com> wrote:
[color=blue]
> Is there any way to know in which direction stack grows[/color]

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

Richard

[dandelion]

Re: doubt on regarding stacks


"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
news:421dbcd8.6 8437036@news.in dividual.net...[color=blue]
> "pmm" <muralipmanohar @hotmail.com> wrote:
>[color=green]
> > Is there any way to know in which direction stack grows[/color]
>
> Not in ISO C. In fact, ISO C does not guarantee that you even _have_ a
> stack as you understand that term.[/color]

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.

[pmm]

Re: doubt on regarding stacks


dandelion wrote:[color=blue]
> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
> news:421dbcd8.6 8437036@news.in dividual.net...[color=green]
> > "pmm" <muralipmanohar @hotmail.com> wrote:
> >[color=darkred]
> > > Is there any way to know in which direction stack grows[/color]
> >
> > Not in ISO C. In fact, ISO C does not guarantee that you even[/color][/color]
_have_ a[color=blue][color=green]
> > stack as you understand that term.[/color]
>
> Correct, of course, but OTOH, you would have a pretty unusual[/color]
platform if[color=blue]
> 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[/color]
another[color=blue]
> local and take that address,too. Then a simple comparison of the[/color]
addresses[color=blue]
> would yield the direction in which the stack grows (assuming your[/color]
compiler[color=blue]
> 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[/color]
platform.[color=blue]
>
> Usually consulting the documentation on your CPU/Compiler will yield[/color]
more[color=blue]
> reliable answers.[/color]

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

[infobahn]

Re: doubt on regarding stacks

pmm wrote:[color=blue]
>
> Hi all,
> Plz dont fire at me if this is a silly question
> Is there any way to know in which direction stack grows[/color]

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

[pmm]

Re: doubt on regarding stacks

Thanks for the reply
your answer is very informative

[dandelion]

Re: doubt on regarding stacks


"pmm" <muralipmanohar @hotmail.com> wrote in message
news:1109247536 .492114.200430@ o13g2000cwo.goo glegroups.com.. .[color=blue]
>
> dandelion wrote:[color=green]
> > "Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
> > news:421dbcd8.6 8437036@news.in dividual.net...[color=darkred]
> > > "pmm" <muralipmanohar @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[/color][/color]
> _have_ a[color=green][color=darkred]
> > > stack as you understand that term.[/color]
> >
> > Correct, of course, but OTOH, you would have a pretty unusual[/color]
> platform if[color=green]
> > 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[/color]
> another[color=green]
> > local and take that address,too. Then a simple comparison of the[/color]
> addresses[color=green]
> > would yield the direction in which the stack grows (assuming your[/color]
> compiler[color=green]
> > 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[/color]
> platform.[color=green]
> >
> > Usually consulting the documentation on your CPU/Compiler will yield[/color]
> more[color=green]
> > reliable answers.[/color]
>
> Thanks for the reply
> I sure did the above trick but I felt like a bad practice.[/color]

It is.
[color=blue]
> I thought of to have a better code so I posted into this group.
>
> plz let me know the correct concepts.[/color]

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.

[Chris Dollin]

Re: doubt on regarding stacks

pmm wrote:
[color=blue]
> Hi all,
> Plz dont fire at me if this is a silly question
> Is there any way to know in which direction stack grows[/color]

Not portably.

Why do you think you need to know?

--
Chris "electric hedgehog" Dollin

[Kiru Sengal]

Re: doubt on regarding stacks

pmm wrote:[color=blue]
> 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[/color]

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. Robert Tisdale]

Re: doubt on regarding stacks

pmm wrote:
[color=blue]
> Is there any way to know
> in which direction stack grows?[/color]

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
"decremente d" when you "push" objects onto the program stack and
"incremente d" when you "pop" objects off of the program stack.

[Keith Thompson]

Re: doubt on regarding stacks

"E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > writes:[color=blue]
> pmm wrote:
>[color=green]
>> Is there any way to know in which direction stack grows?[/color]
>
> 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
> "decremente d" when you "push" objects onto the program stack and
> "incremente d" when you "pop" objects off of the program stack.[/color]

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_ad dr);
printf("Object in func() is at [%p]\n", (void*)&inner_o bj);
#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_Keit h) kst-u@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.

[Nils Weller]

Re: doubt on regarding stacks

In article <lnoee91tn4.fsf @nuthaus.mib.or g>, Keith Thompson wrote:[color=blue]
> "E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > writes:[color=green]
>> pmm wrote:
>>[color=darkred]
>>> Is there any way to know in which direction stack grows?[/color]
>>
>> A stack always grows upward. Unfortunately,[/color][/color]

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

[...]
[color=blue]
>
> 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.[/color]

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>gnuli nux<dot>nl''

[Neil Kurzman]

Re: doubt on regarding stacks



dandelion wrote:
[color=blue]
> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
> news:421dbcd8.6 8437036@news.in dividual.net...[color=green]
> > "pmm" <muralipmanohar @hotmail.com> wrote:
> >[color=darkred]
> > > Is there any way to know in which direction stack grows[/color]
> >
> > Not in ISO C. In fact, ISO C does not guarantee that you even _have_ a
> > stack as you understand that term.[/color]
>
> Correct, of course, but OTOH, you would have a pretty unusual platform if
> you did not.
>[/color]

many 8bitters the PIC and 8051 for example.

[color=blue]
>
> 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.[/color]

[Neil Kurzman]

Re: doubt on regarding stacks



"E. Robert Tisdale" wrote:
[color=blue]
> pmm wrote:
>[color=green]
> > Is there any way to know
> > in which direction stack grows?[/color]
>
> 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
> "decremente d" when you "push" objects onto the program stack and
> "incremente d" when you "pop" objects off of the program stack.[/color]

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. Robert Tisdale]

Re: doubt on regarding stacks

Neil Kurzman wrote:
[color=blue]
> 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.[/color]

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.