stack increase direction and big-endian or little-endia

Discussion in 'C++' started by gary, Oct 23, 2005.

  1. gary

    gary Guest

    Hi,

    1. About all C/C++ compilers, Does stack increase from high address to low address and heap grow increase from low to high? What on earth decides their increase direction, CPU architecture, OS or compiler?

    2. In GNU gcc,
    {
    int a[] = {0, 1, 2, 3, 4};
    bool b;
    float c;
    for (int i = 0; i < 5; i++) {
    cout << hex << a+i << "," ;
    }
    cout << endl;
    cout << hex << &a << "," << &b << "," << &c << endl;
    }
    one print result is: 0x22ff40, 0x22ff44, 0x22ff48, 0x22ff4c, 0x22ff50
    0x22ff40, 0x22ff3f, 0x22ff38
    So considering question one, why the address of the array(a) increased to high address?


    3. What decides the big-endian and little-endian, CPU architecture, OS or compiler?

    4. {
    int x = 0x12345678;
    char *cp = (char*)&x;
    for(int i = 0; i < 4; i++) {
    cout << hex << (int)*(cp+i) << " ";
    }
    }
    what is run result?
    I think it depends on two aspects: stack increase direction and big-endian or little-endia.
    Considering in the case of big-endian, suppose the address of x is 0x22ff44, namely &x=0x22ff44, and sizeof(x)=4.
    If stack increases to low address, the variable x occupied 0x22ff44, 0x22ff43, 0x22ff42 and 0x22ff41, so the result is "78 56 34 12".
    If stack increases to high address, the variable x occupied 0x22ff44, 0x22ff45, 0x22ff46 and 0x22ff47, so the result is "12 34 56 78".

    Please give me some advice, thank you.
    gary, Oct 23, 2005
    #1
    1. Advertising

  2. gary wrote:
    > Hi,
    >
    > 1. About all C/C++ compilers, Does stack increase from high address to low address and heap grow increase from low to high? What on earth decides their increase direction, CPU architecture, OS or compiler?
    >
    > 2. In GNU gcc,
    > {
    > int a[] = {0, 1, 2, 3, 4};
    > bool b;
    > float c;
    > for (int i = 0; i < 5; i++) {
    > cout << hex << a+i << "," ;
    > }
    > cout << endl;
    > cout << hex << &a << "," << &b << "," << &c << endl;
    > }
    > one print result is: 0x22ff40, 0x22ff44, 0x22ff48, 0x22ff4c, 0x22ff50
    > 0x22ff40, 0x22ff3f, 0x22ff38
    > So considering question one, why the address of the array(a) increased to high address?
    >
    >
    > 3. What decides the big-endian and little-endian, CPU architecture, OS or compiler?
    >
    > 4. {
    > int x = 0x12345678;
    > char *cp = (char*)&x;
    > for(int i = 0; i < 4; i++) {
    > cout << hex << (int)*(cp+i) << " ";
    > }
    > }
    > what is run result?
    > I think it depends on two aspects: stack increase direction and big-endian or little-endia.
    > Considering in the case of big-endian, suppose the address of x is 0x22ff44, namely &x=0x22ff44, and sizeof(x)=4.
    > If stack increases to low address, the variable x occupied 0x22ff44, 0x22ff43, 0x22ff42 and 0x22ff41, so the result is "78 56 34 12".
    > If stack increases to high address, the variable x occupied 0x22ff44, 0x22ff45, 0x22ff46 and 0x22ff47, so the result is "12 34 56 78".
    >
    > Please give me some advice, thank you.




    all three
    Andrej Hristoliubov, Oct 23, 2005
    #2
    1. Advertising

  3. gary

    Greg Guest

    gary wrote:
    > Hi,
    >
    > 1. About all C/C++ compilers, Does stack increase from high address to low address and heap grow increase from low to high? What on earth decides their increase direction, CPU architecture, OS or compiler?


    The direction that the stack and heap grows is OS-dependent and has
    nothing to do with C or C++ compilers. Generally, one can expect that
    the heap and the stack will grow in opposite directions and from
    opposite ends of the logical address space (in order that they not
    collide unnecessarily).

    >
    > 2. In GNU gcc,
    > {
    > int a[] = {0, 1, 2, 3, 4};
    > bool b;
    > float c;
    > for (int i = 0; i < 5; i++) {
    > cout << hex << a+i << "," ;
    > }
    > cout << endl;
    > cout << hex << &a << "," << &b << "," << &c << endl;
    > }
    > one print result is: 0x22ff40, 0x22ff44, 0x22ff48, 0x22ff4c, 0x22ff50
    > 0x22ff40, 0x22ff3f, 0x22ff38
    > So considering question one, why the address of the array(a) increased to high address?


    No matter which direction the heap or stack may grow, objects in
    memory, including arrays will have the same layout. Each element in an
    array will stored at a higher memory location than the element before
    it.

    >
    > 3. What decides the big-endian and little-endian, CPU architecture, OS or compiler?


    The CPU may only support one kind of endianness, or the OS may be
    written for a particular endian-ness. Of course endianness is just a
    convention for storing multibyte data. As such, a program is free to
    use either convention (or make up its own) with its own data. Generally
    in the interests of inter-operabillity and consistency, it is best to
    use the same endianess that the OS prefers.

    > 4. {
    > int x = 0x12345678;
    > char *cp = (char*)&x;
    > for(int i = 0; i < 4; i++) {
    > cout << hex << (int)*(cp+i) << " ";
    > }
    > }
    > what is run result?


    On a big endian machine: 12 34 56 78
    little-endian: 78 56 34 21

    > I think it depends on two aspects: stack increase direction and big-endian or little-endia.


    The direction the stack increases has no effect on how x would be
    stored in memory.

    > Considering in the case of big-endian, suppose the address of x is 0x22ff44, namely &x=0x22ff44, and sizeof(x)=4.
    > If stack increases to low address, the variable x occupied 0x22ff44, 0x22ff43, 0x22ff42 and 0x22ff41, so the result is "78 56 34 12".
    > If stack increases to high address, the variable x occupied 0x22ff44, 0x22ff45, 0x22ff46 and 0x22ff47, so the result is "12 34 56 78".


    No, only the endianness used to store x would affect the order in which
    its bytes are arranged in memory.

    Greg
    Greg, Oct 23, 2005
    #3
  4. >1. About all C/C++ compilers, Does stack increase from high address to low address and heap grow increase from low to high? What on earth >decides their increase direction, CPU architecture, OS or compiler?

    In most cases, it is the CPU architecture. In some cases where the
    processor allows the stack to grow in either direction, the compiler
    might provide a switch to choose between the two.

    >2. In GNU gcc,
    > {
    > int a[] = {0, 1, 2, 3, 4};
    > ...
    >So considering question one, why the address of the array(a) increased to high address?


    The space for the entire array is allocated in one stroke. Individual
    array elements are not pushed on the stack. Note that C arrays operate
    the same way regardless of the variables location on stack, heap or
    global memory.


    > 3. What decides the big-endian and little-endian, CPU architecture, OS or compiler?


    In most cases, it is the CPU architecture. In some cases where the
    processor supports little as well as big endian operation, the compiler
    might provide a switch to choose between the two.

    The following article should help:

    http://www.eventhelix.com/RealtimeMantra/ByteAlignmentAndOrdering.htm

    --
    EventStudio System Designer 2.5 - http://www.EventHelix.com/EventStudio
    Sequence Diagram Based System Design and Object Modeling Tool
    EventHelix.com, Oct 23, 2005
    #4
    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. Eric J.Hu
    Replies:
    3
    Views:
    831
    Alexei A. Frounze
    Aug 29, 2005
  2. Replies:
    5
    Views:
    346
    Stephen Sprunk
    Aug 31, 2006
  3. Eric J.Hu
    Replies:
    7
    Views:
    530
    Jim Langston
    Sep 7, 2005
  4. aling
    Replies:
    8
    Views:
    950
    Pete Becker
    Oct 19, 2005
  5. bhatia

    Big Endian and Little Endian

    bhatia, Jul 7, 2006, in forum: C++
    Replies:
    2
    Views:
    476
    Robbie Hatley
    Jul 7, 2006
Loading...

Share This Page