direction of stack growth

Discussion in 'C Programming' started by junky_fellow@yahoo.co.in, Apr 19, 2006.

  1. Guest

    Hi all,

    Is there any way by which we mat determine the direction of stack
    growth (from
    higher address to lower address Or from lower address to higher
    address) ?
    I know this question is implementation specific and this may not be the
    correct place
    to ask this. But any hints would help me a lot.

    I thought of the following way (assuming that the implementation uses
    stack to
    save the local variables as for instance in m68k processor).
    In a function f1(), declare a local variable (local1).
    save its address. Call another function f2() from f1 and in f2()
    declare another local
    variable (local2) and return its address to f1(). Now, compare the
    addresses of local1
    and local2 to determine the direction of stack growth.

    Is this the right way of doing it ? Can we compare the adresses of the
    local variables
    local1 and local ? If not, what is the right of doing it ?
    Also, some of the implementations don't use stack to store the local
    variables. They store
    the local varaibles in registers. In those implementations what would
    happen if I try
    to print address of local variable (using &local1) ? I am asking this,
    as the local
    variable may not have been allocated on stack or some memory location.
    The compiler
    might have used some general purpose register for that. In that case,
    what output
    we will get if we print the address of a local variable ?


    Thanx for any help/hint ....
    , Apr 19, 2006
    #1
    1. Advertising

  2. Chris Dollin Guest

    wrote:

    > Hi all,
    >
    > Is there any way by which we mat determine the direction of stack
    > growth (from
    > higher address to lower address Or from lower address to higher
    > address) ?


    There is no portable way to do this. On an given implementation, the
    question might even be meaningless. (Consider a C implementation on
    a Lispy machine where stack frames are allocated from the heap.)

    Why do you want to know, anyway?

    --
    Chris "not a Tuvela" Dollin
    "To say that the human is thus and so is almost always to lie automatically."
    Chris Dollin, Apr 19, 2006
    #2
    1. Advertising

  3. Guest

    Chris Dollin wrote:
    > wrote:
    >
    > > Hi all,
    > >
    > > Is there any way by which we mat determine the direction of stack
    > > growth (from
    > > higher address to lower address Or from lower address to higher
    > > address) ?

    >
    > There is no portable way to do this. On an given implementation, the
    > question might even be meaningless. (Consider a C implementation on
    > a Lispy machine where stack frames are allocated from the heap.)
    >
    > Why do you want to know, anyway?


    I know, this cannot be done portably. But, can you suggest some way for
    a
    specific implementation (as for instance motorola's 68k processor) ?
    , Apr 19, 2006
    #3
  4. "" <> writes:
    > Hi all,
    >
    > Is there any way by which we mat determine the direction of
    > stack growth (from higher address to lower address Or from lower
    > address to higher address) ? I know this question is implementation
    > specific and this may not be the correct place to ask this. But any
    > hints would help me a lot.


    There is no portable way to determine this.

    > I thought of the following way (assuming that the implementation
    > uses stack to save the local variables as for instance in m68k
    > processor). In a function f1(), declare a local variable (local1).
    > save its address. Call another function f2() from f1 and in f2()
    > declare another local variable (local2) and return its address to
    > f1(). Now, compare the addresses of local1 and local2 to determine
    > the direction of stack growth.


    Relational operators on pointer values are defined only when both
    pointers point within the same object (or just past the end of it).
    A comparison like "&local1 < &local2" invokes undefined behavior.

    It's likely to work as you expect on most implementations, but it's
    not guaranteed by the standard.


    > Is this the right way of doing it ? Can we compare the adresses of
    > the local variables local1 and local ? If not, what is the right of
    > doing it ? Also, some of the implementations don't use stack to
    > store the local variables. They store the local varaibles in
    > registers. In those implementations what would happen if I try to
    > print address of local variable (using &local1) ? I am asking this,
    > as the local variable may not have been allocated on stack or some
    > memory location. The compiler might have used some general purpose
    > register for that. In that case, what output we will get if we print
    > the address of a local variable ?


    You can legally take the address of any object that's not declared
    with the "register" keyword. If the implementation chooses to store
    the object in a register, it must also store it in memory if you take
    its address. (Most likely, taking the address of an object will cause
    the compiler *not* to store it in a register.)

    --
    Keith Thompson (The_Other_Keith) <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.
    Keith Thompson, Apr 19, 2006
    #4
  5. Flash Gordon Guest

    wrote:
    > Chris Dollin wrote:
    >> wrote:
    >>
    >>> Hi all,
    >>>
    >>> Is there any way by which we mat determine the direction of stack
    >>> growth (from
    >>> higher address to lower address Or from lower address to higher
    >>> address) ?

    >> There is no portable way to do this. On an given implementation, the
    >> question might even be meaningless. (Consider a C implementation on
    >> a Lispy machine where stack frames are allocated from the heap.)
    >>
    >> Why do you want to know, anyway?

    >
    > I know, this cannot be done portably.


    Then you know it is not topical here since you've been around here before.

    > But, can you suggest some way for
    > a
    > specific implementation (as for instance motorola's 68k processor) ?


    Yes, read the documentation.
    --
    Flash Gordon, living in interesting times.
    Web site - http://home.flash-gordon.me.uk/
    comp.lang.c posting guidelines and intro:
    http://clc-wiki.net/wiki/Intro_to_clc
    Flash Gordon, Apr 19, 2006
    #5
  6. Chris Dollin Guest

    wrote:

    >
    > Chris Dollin wrote:
    >> wrote:
    >>
    >> > Hi all,
    >> >
    >> > Is there any way by which we mat determine the direction of stack
    >> > growth (from
    >> > higher address to lower address Or from lower address to higher
    >> > address) ?

    >>
    >> There is no portable way to do this. On an given implementation, the
    >> question might even be meaningless. (Consider a C implementation on
    >> a Lispy machine where stack frames are allocated from the heap.)
    >>
    >> Why do you want to know, anyway?

    >
    > I know, this cannot be done portably. But, can you suggest some way for
    > a
    > specific implementation (as for instance motorola's 68k processor) ?


    Not apart from the non-portable method you suggest.

    But /why/ do you want to know this?

    --
    Chris "not a Tuvela" Dollin
    "To say that the human is thus and so is almost always to lie automatically."
    Chris Dollin, Apr 19, 2006
    #6
  7. Tim Prince Guest

    Chris Dollin wrote:
    > wrote:
    >
    >> Chris Dollin wrote:
    >>> wrote:
    >>>
    >>>> Hi all,
    >>>>
    >>>> Is there any way by which we mat determine the direction of stack
    >>>> growth (from
    >>>> higher address to lower address Or from lower address to higher
    >>>> address) ?
    >>> There is no portable way to do this. On an given implementation, the
    >>> question might even be meaningless. (Consider a C implementation on
    >>> a Lispy machine where stack frames are allocated from the heap.)
    >>>
    >>> Why do you want to know, anyway?

    >> I know, this cannot be done portably. But, can you suggest some way for
    >> a
    >> specific implementation (as for instance motorola's 68k processor) ?

    >
    > Not apart from the non-portable method you suggest.
    >
    > But /why/ do you want to know this?
    >

    Are you trying to second guess the way it's done in gcc build? Surely
    it worked at some time in the past, if not now. Why not go to a
    newsgroup where this is on topic?
    Tim Prince, Apr 19, 2006
    #7
  8. On Wed, 19 Apr 2006 04:28:45 -0700, wrote:

    >
    > Chris Dollin wrote:
    >> wrote:
    >>
    >> > Hi all,
    >> >
    >> > Is there any way by which we mat determine the direction of stack
    >> > growth (from
    >> > higher address to lower address Or from lower address to higher
    >> > address) ?

    >>
    >> There is no portable way to do this. On an given implementation, the
    >> question might even be meaningless. (Consider a C implementation on
    >> a Lispy machine where stack frames are allocated from the heap.)
    >>
    >> Why do you want to know, anyway?

    >
    > I know, this cannot be done portably. But, can you suggest some way for
    > a
    > specific implementation (as for instance motorola's 68k processor) ?

    You could look at the assembly code output from the compiler.
    Duncan
    Duncan Muirhead, Apr 19, 2006
    #8
  9. Guest

    Keith Thompson wrote:
    > "" <> writes:
    > > Hi all,
    > >
    > > Is there any way by which we mat determine the direction of
    > > stack growth (from higher address to lower address Or from lower
    > > address to higher address) ? I know this question is implementation
    > > specific and this may not be the correct place to ask this. But any
    > > hints would help me a lot.

    >
    > There is no portable way to determine this.
    >
    > > I thought of the following way (assuming that the implementation
    > > uses stack to save the local variables as for instance in m68k
    > > processor). In a function f1(), declare a local variable (local1).
    > > save its address. Call another function f2() from f1 and in f2()
    > > declare another local variable (local2) and return its address to
    > > f1(). Now, compare the addresses of local1 and local2 to determine
    > > the direction of stack growth.

    >
    > Relational operators on pointer values are defined only when both
    > pointers point within the same object (or just past the end of it).
    > A comparison like "&local1 < &local2" invokes undefined behavior.
    >
    > It's likely to work as you expect on most implementations, but it's
    > not guaranteed by the standard.
    >


    Thanx a lot for your help. I have one more doubt that why it is illegal
    to
    compare the addresses of two local variables ? One reason I may think
    of
    is that pointers are not plain integers and they may be composed of
    base and offset. But, in that case as well, the base address of the
    segment
    (stack segment ) should be the same as both the local variables are on
    the same stack (although the stack frames are different).
    So, why their comparison is illegal ?
    , Apr 19, 2006
    #9
  10. Chris Dollin Guest

    wrote:

    > Keith Thompson wrote:
    >> Relational operators on pointer values are defined only when both
    >> pointers point within the same object (or just past the end of it).
    >> A comparison like "&local1 < &local2" invokes undefined behavior.
    >>
    >> It's likely to work as you expect on most implementations, but it's
    >> not guaranteed by the standard.
    >>

    >
    > Thanx a lot for your help. I have one more doubt that why it is illegal
    > to
    > compare the addresses of two local variables ?


    It's not /illegal/. It's /undefined/.

    I believe it's to allow implementations the leeway to implement pointer
    comparision as efficiently as possible. By only specifying the behaviour
    of pointer comparison when the pointers point into the same array [1],
    the implementation is at liberty to assume compared pointers point
    into the same entity.

    So a (some) segmented implementation(s) might only compare the offset
    and not the segment, if that was more efficient than comparing both.

    Also note that local variables can be stored in any order the compiler
    wants, independantly of the order the stack grows in. EG it might put
    the most-used locals in registers, the next-most-used in stack locations
    that are cheap to access [2], and the less-used ones in more expensive
    locations. The declaration `int a, b;` could put `a` before or after
    `b`, depending on their use patterns. The compiler is not obliged
    to discard efficiency just because of an accident of source ordering.

    [1] Or array-like entity - mallocated store - or one-past-the-end.

    [2] Like `(sp)` on the PDP-11.

    --
    Chris "not a Tuvela" Dollin
    "To say that the human is thus and so is almost always to lie automatically."
    Chris Dollin, Apr 19, 2006
    #10
  11. In article <>,
    <> wrote:

    >Thanx a lot for your help. I have one more doubt that why it is
    >illegal to compare the addresses of two local variables ? One reason
    >I may think of is that pointers are not plain integers and they may
    >be composed of base and offset. But, in that case as well, the base
    >address of the segment (stack segment ) should be the same as both
    >the local variables are on the same stack (although the stack frames
    >are different). So, why their comparison is illegal ?


    Typical C implementations use a stack, but there's no requirement to.
    An implementation is free to store each function call's variables in a
    different segment for example. So the standard doesn't require
    comparisons (except equality comparisons) to work.

    For typical implementations on current hardware, comparing the
    addresses will do what you expect. If I remember correctly, Doug
    Gwyn's "portable" alloca() used this method.

    -- Richard
    Richard Tobin, Apr 19, 2006
    #11
  12. Chris Dollin Guest

    Chris Dollin wrote:

    > I believe it's to allow implementations the leeway to implement pointer
    > comparision as efficiently as possible. By only specifying the behaviour
    > of pointer comparison when the pointers point into the same array [1],


    <fx:mumble face="red">can't remember whether this is for equality too</>.

    --
    Chris "not a Tuvela" Dollin
    "To say that the human is thus and so is almost always to lie automatically."
    Chris Dollin, Apr 19, 2006
    #12
  13. "" wrote:
    >
    > Chris Dollin wrote:
    > > wrote:
    > >
    > > > Hi all,
    > > >
    > > > Is there any way by which we mat determine the direction of stack
    > > > growth (from
    > > > higher address to lower address Or from lower address to higher
    > > > address) ?

    > >
    > > There is no portable way to do this. On an given implementation, the
    > > question might even be meaningless. (Consider a C implementation on
    > > a Lispy machine where stack frames are allocated from the heap.)
    > >
    > > Why do you want to know, anyway?

    >
    > I know, this cannot be done portably. But, can you suggest some way for
    > a specific implementation (as for instance motorola's 68k processor) ?


    Well, if you know the processor, you know that stack order already. :)

    However, something like this _may_ work in a stack-based implementation:

    #include <stdio.h>

    void foo(int *);
    int main(int argc,char *argv[])
    {
    int i;
    foo(&i);
    }
    void foo(int *ii)
    {
    int j;
    if ( &j < ii )
    printf("I think the stack grows down.\n");
    else if ( &j > ii )
    printf("I think the stack grows up.\n");
    else
    printf("I'm really confused now.\n");
    }

    --
    +-------------------------+--------------------+-----------------------------+
    | Kenneth J. Brody | www.hvcomputer.com | |
    | kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Apr 19, 2006
    #13
  14. In article <>,
    Kenneth Brody <> wrote:

    >Well, if you know the processor, you know that stack order already. :)


    Not at all! Many processors make it easier to run stacks in some
    particular direction, but it would be quite possible to write a C
    implementation that didn't follow the convention.

    -- Richard
    Richard Tobin, Apr 19, 2006
    #14
  15. Richard Tobin wrote:
    >
    > In article <>,
    > Kenneth Brody <> wrote:
    >
    > >Well, if you know the processor, you know that stack order already. :)

    >
    > Not at all! Many processors make it easier to run stacks in some
    > particular direction, but it would be quite possible to write a C
    > implementation that didn't follow the convention.


    True, but probably the only reason to do so would be to break programs
    that assumed otherwise. :)

    --
    +-------------------------+--------------------+-----------------------------+
    | Kenneth J. Brody | www.hvcomputer.com | |
    | kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Apr 19, 2006
    #15
  16. In article <>,
    Kenneth Brody <> wrote:
    >Richard Tobin wrote:


    >> In article <>,
    >> Kenneth Brody <> wrote:


    >> >Well, if you know the processor, you know that stack order already. :)


    >> Not at all! Many processors make it easier to run stacks in some
    >> particular direction, but it would be quite possible to write a C
    >> implementation that didn't follow the convention.


    >True, but probably the only reason to do so would be to break programs
    >that assumed otherwise. :)


    Or to increase compatability with programs that assumed a particular
    direction.

    Another point is that some processors are able to run in multiple modes,
    not all of which will necessarily have the same optimal stack direction.

    [I'm thinking of the MIPS ability to run either endian; I don't recall
    whether that has any effect on best stack growth or upon "conventional"
    stack growth.]
    --
    All is vanity. -- Ecclesiastes
    Walter Roberson, Apr 19, 2006
    #16
  17. Flash Gordon Guest

    Richard Tobin wrote:
    > In article <>,
    > Kenneth Brody <> wrote:
    >
    >> Well, if you know the processor, you know that stack order already. :)

    >
    > Not at all! Many processors make it easier to run stacks in some
    > particular direction, but it would be quite possible to write a C
    > implementation that didn't follow the convention.


    On one processor I've used it is just as easy (and has no performance
    penalty) to make the stack grow in either direction.
    --
    Flash Gordon, living in interesting times.
    Web site - http://home.flash-gordon.me.uk/
    comp.lang.c posting guidelines and intro:
    http://clc-wiki.net/wiki/Intro_to_clc
    Flash Gordon, Apr 19, 2006
    #17
  18. Chris Dollin <> writes:
    > Chris Dollin wrote:
    >
    >> I believe it's to allow implementations the leeway to implement pointer
    >> comparision as efficiently as possible. By only specifying the behaviour
    >> of pointer comparison when the pointers point into the same array [1],

    >
    > <fx:mumble face="red">can't remember whether this is for equality too</>.


    Equality comparison is defined for pointers to distinct objects (and
    yields 0).

    C99 6.5.9:

    Two pointers compare equal if and only if both are null pointers,
    both are pointers to the same object (including a pointer to an
    object and a subobject at its beginning) or function, both are
    pointers to one past the last element of the same array object, or
    one is a pointer to one past the end of one array object and the
    other is a pointer to the start of a different array object that
    happens to immediately follow the first array object in the
    address space.

    And n1124 adds:

    For the purposes of these operators, a pointer to an object that
    is not an element of an array behaves the same as a pointer to the
    first element of an array of length one with the type of the
    object as its element type.

    --
    Keith Thompson (The_Other_Keith) <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.
    Keith Thompson, Apr 19, 2006
    #18
  19. Jack Klein Guest

    On Wed, 19 Apr 2006 10:43:35 -0400, Kenneth Brody
    <> wrote in comp.lang.c:

    > "" wrote:
    > >
    > > Chris Dollin wrote:
    > > > wrote:
    > > >
    > > > > Hi all,
    > > > >
    > > > > Is there any way by which we mat determine the direction of stack
    > > > > growth (from
    > > > > higher address to lower address Or from lower address to higher
    > > > > address) ?
    > > >
    > > > There is no portable way to do this. On an given implementation, the
    > > > question might even be meaningless. (Consider a C implementation on
    > > > a Lispy machine where stack frames are allocated from the heap.)
    > > >
    > > > Why do you want to know, anyway?

    > >
    > > I know, this cannot be done portably. But, can you suggest some way for
    > > a specific implementation (as for instance motorola's 68k processor) ?

    >
    > Well, if you know the processor, you know that stack order already. :)


    Not really. ARM, for example, can build stacks in either direction,
    with no difference in code size or execution speed.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Apr 20, 2006
    #19
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Generic Usenet Account

    Tracking the "memory growth" of a process

    Generic Usenet Account, Apr 5, 2004, in forum: C++
    Replies:
    5
    Views:
    457
    Kevin Goodsell
    Apr 6, 2004
  2. Generic Usenet Account

    Tracking the "memory growth" of a process

    Generic Usenet Account, Apr 5, 2004, in forum: C Programming
    Replies:
    4
    Views:
    330
    Kevin Goodsell
    Apr 6, 2004
  3. sam
    Replies:
    3
    Views:
    361
    Kent Johnson
    Mar 19, 2005
  4. Adam Warner

    Detect direction of stack growth

    Adam Warner, Dec 27, 2004, in forum: C Programming
    Replies:
    6
    Views:
    321
    Malcolm
    Dec 27, 2004
  5. gary
    Replies:
    3
    Views:
    1,441
    EventHelix.com
    Oct 23, 2005
Loading...

Share This Page