How do we know the memory arrangement using in microprocessors? Top-Bottom or Bottom-Top?

Discussion in 'C Programming' started by Cuthbert, Sep 13, 2006.

  1. Cuthbert

    Cuthbert Guest

    Hi folks,

    This question is a little deep into memory management of
    microprocessor.
    How do we know the memory arrangement using in microprocessors?
    Top-Bottom or Bottom-Top?

    For example, the "Top-Bottom" is arranging memory resource from higher
    address to lower address.

    If we have no hardware knowledge of microprocessors, how can we know
    the arrangement of microprocessors?

    I have idea which is declearing an array and check the addresses of
    array elements because the allocation of array elements is sequential.
    And, then, we know how memory resource is arranged.

    BUT, is there any other way to find out?

    Cuthbert
    ===================================
    int main (void)
    {
    char var[10];
    int i;
    for ( i = 0; i < 10; i++)
    printf("addr = %X\n", &var);

    return 0;
    }

    // Bottom-Top arrangement:
    // Result:
    $ ./addr
    addr = BF9CEF66
    addr = BF9CEF67
    addr = BF9CEF68
    addr = BF9CEF69
    addr = BF9CEF6A
    addr = BF9CEF6B
    addr = BF9CEF6C
    addr = BF9CEF6D
    addr = BF9CEF6E
    addr = BF9CEF6F
    $
    Cuthbert, Sep 13, 2006
    #1
    1. Advertising

  2. Re: How do we know the memory arrangement using in microprocessors?Top-Bottom or Bottom-Top?

    "Cuthbert" <> writes:
    > This question is a little deep into memory management of
    > microprocessor.
    > How do we know the memory arrangement using in microprocessors?
    > Top-Bottom or Bottom-Top?
    >
    > For example, the "Top-Bottom" is arranging memory resource from higher
    > address to lower address.


    I don't think that's even meaningful.

    > If we have no hardware knowledge of microprocessors, how can we know
    > the arrangement of microprocessors?
    >
    > I have idea which is declearing an array and check the addresses of
    > array elements because the allocation of array elements is sequential.
    > And, then, we know how memory resource is arranged.
    >
    > BUT, is there any other way to find out?
    >
    > Cuthbert
    > ===================================
    > int main (void)
    > {
    > char var[10];
    > int i;
    > for ( i = 0; i < 10; i++)
    > printf("addr = %X\n", &var);
    >
    > return 0;
    > }


    Since you're using printf(), you *must* have a "#include <stdio.h>" at
    the top of your program.

    The "%X" format expects an unsigned int; you're giving it a char*,
    which invokes undefined behavior. Use "%p" to print pointers.

    Here's a corrected version of your program:

    #include <stdio.h>
    int main (void)
    {
    char var[10];
    int i;
    for ( i = 0; i < 10; i++)
    printf("addr = %p\n", (void*)&var);

    return 0;
    }

    > // Bottom-Top arrangement:
    > // Result:
    > $ ./addr
    > addr = BF9CEF66
    > addr = BF9CEF67
    > addr = BF9CEF68
    > addr = BF9CEF69
    > addr = BF9CEF6A
    > addr = BF9CEF6B
    > addr = BF9CEF6C
    > addr = BF9CEF6D
    > addr = BF9CEF6E
    > addr = BF9CEF6F


    With the corrected program, I get:

    addr = 0x22ccd0
    addr = 0x22ccd1
    addr = 0x22ccd2
    addr = 0x22ccd3
    addr = 0x22ccd4
    addr = 0x22ccd5
    addr = 0x22ccd6
    addr = 0x22ccd7
    addr = 0x22ccd8
    addr = 0x22ccd9

    Array elements are always allocated at increasing addresses, by
    definition. Displaying the addresses isn't necessarily going to tell
    you anything; using "%X" can give you completely meaningless result,
    and even "%p" gives you implementation-defined results.

    You can compare addresses of array elements using "<", and ">" (since
    the addresses are within the same object). For example:

    #include <stdio.h>
    int main (void)
    {
    char var[10];
    int i;
    for ( i = 0; i < 9; i++) {
    if (&var < &var[i+1]) {
    printf("&var[%d] < &var[%d]\n", i, i+1);
    }
    else if (&var == &var[i+1]) {
    printf("&var[%d] == &var[%d] (?)\n", i, i+1);
    }
    else if (&var > &var[i+1]) {
    printf("&var[%d] > &var[%d] (?)\n", i, i+1);
    }
    else {
    printf("&var[%d] and &var[%d] are incomparable (?)\n", i, i+1);
    }
    }
    return 0;
    }

    But this still tells you nothing about the CPU architecture. If the
    program produces any output other than:

    &var[0] < &var[1]
    &var[1] < &var[2]
    &var[2] < &var[3]
    &var[3] < &var[4]
    &var[4] < &var[5]
    &var[5] < &var[6]
    &var[6] < &var[7]
    &var[7] < &var[8]
    &var[8] < &var[9]

    on *any* system, then there's a serious problem, probably a compiler
    bug.

    If you're asking the order in which memory is *allocated* (say, for
    successive function calls), there is no *portable* way to determine
    this. On many systems, the system stack grows either from high to low
    addresses, or vice versa, and there's likely to be some non-portable
    way to determine which. (You'd have to compare addresses of distinct
    objects, which invokes undefined behavior.) Other systems may not use
    a system stack in the usual sense at all.

    If you want to write portable code, there's no reason why you should
    care one way or the other.

    --
    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, Sep 13, 2006
    #2
    1. Advertising

  3. Cuthbert

    Cuthbert Guest

    Thanks a lot for your reply, Keith.

    In the view of C language, the addressese of array elements are always
    increased along the index. Which means my way cannot relect the real
    order of memony allocation.

    At last, you said "(You'd have to compare addresses of distinct
    objects, which invokes undefined behavior.)." However, the addresses,
    or locations, of the static or local objects are optimized by
    compilers, their addresses can tell nothing about the arrangement.

    How about dynamic objects? Can they tell me the order of memory
    allocation?

    Cuthbert


    Keith Thompson wrote:
    > "Cuthbert" <> writes:
    > > This question is a little deep into memory management of

    ......................
    Cuthbert, Sep 13, 2006
    #3
  4. Re: How do we know the memory arrangement using in microprocessors?Top-Bottom or Bottom-Top?

    "Cuthbert" <> writes:
    > Thanks a lot for your reply, Keith.
    >
    > In the view of C language, the addressese of array elements are always
    > increased along the index. Which means my way cannot relect the real
    > order of memony allocation.


    That (almost certainly) *is* the real order of memory allocation.

    More precisely, on most hosted systems, C addresses (pointer values)
    directly correspond to machine-level virtual addresses. (On some
    embedded systems, C addresses might correspond to machine-level
    physical addresses.)

    > At last, you said "(You'd have to compare addresses of distinct
    > objects, which invokes undefined behavior.)." However, the addresses,
    > or locations, of the static or local objects are optimized by
    > compilers, their addresses can tell nothing about the arrangement.
    >
    > How about dynamic objects? Can they tell me the order of memory
    > allocation?


    Your question is still very unclear. What exactly are you asking
    about?

    Whatever your actual question is, the answer is almost certainly that
    you can't determine it in portable C, and there's almost certainly no
    good reason why you should care.

    Objects in C are allocated differently depending on their storage
    durations. Objects with "static" storage duration exist throughout
    the execution of the program. Objects with "automatic" storage
    duration, such as (non-static) local objects in functions, exist
    during the execution of the block in which they're declared. Objects
    with "allocated" storage duration are created by malloc(), calloc(),
    or realloc(), and destroyed by free() or realloc() (is this what you
    mean by "dynamic objects"?).

    The language says nothing about the relative addresses of any objects,
    regardless of their storage durations.

    Also, please learn to post properly. See
    <http://cfaj.freeshell.org/google/> and
    <http://www.caliburn.nl/topposting.html>.

    --
    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, Sep 13, 2006
    #4
  5. Cuthbert

    kondal Guest

    Keith Thompson wrote:
    > "Cuthbert" <> writes:
    > > Thanks a lot for your reply, Keith.
    > >
    > > In the view of C language, the addressese of array elements are always
    > > increased along the index. Which means my way cannot relect the real
    > > order of memony allocation.

    >
    > That (almost certainly) *is* the real order of memory allocation.
    >
    > More precisely, on most hosted systems, C addresses (pointer values)
    > directly correspond to machine-level virtual addresses. (On some
    > embedded systems, C addresses might correspond to machine-level
    > physical addresses.)
    >
    > > At last, you said "(You'd have to compare addresses of distinct
    > > objects, which invokes undefined behavior.)." However, the addresses,
    > > or locations, of the static or local objects are optimized by
    > > compilers, their addresses can tell nothing about the arrangement.
    > >
    > > How about dynamic objects? Can they tell me the order of memory
    > > allocation?

    >
    > Your question is still very unclear. What exactly are you asking
    > about?
    >
    > Whatever your actual question is, the answer is almost certainly that
    > you can't determine it in portable C, and there's almost certainly no
    > good reason why you should care.
    >
    > Objects in C are allocated differently depending on their storage
    > durations. Objects with "static" storage duration exist throughout
    > the execution of the program. Objects with "automatic" storage
    > duration, such as (non-static) local objects in functions, exist
    > during the execution of the block in which they're declared. Objects
    > with "allocated" storage duration are created by malloc(), calloc(),
    > or realloc(), and destroyed by free() or realloc() (is this what you
    > mean by "dynamic objects"?).
    >
    > The language says nothing about the relative addresses of any objects,
    > regardless of their storage durations.
    >
    > Also, please learn to post properly. See
    > <http://cfaj.freeshell.org/google/> and
    > <http://www.caliburn.nl/topposting.html>.
    >
    > --
    > 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.


    Just to add Keith's mail, All the local variables are generally stored
    in the stack during the function call (called by many names as
    'activation record', 'function call record', call stack etc. Where as
    the objects created by malloc/calloc/realloc/new are created in the
    heap memory. Compilers (specifically linker) will place global and
    static variables in data section where they are exist through out the
    program.
    This information can be found when you read the linker document of a
    compiler. Storage allocations are interesting topic by itself :)

    -kondal
    kondal, Sep 13, 2006
    #5
  6. Cuthbert

    kondal Guest

    Keith Thompson wrote:
    > "Cuthbert" <> writes:
    > > Thanks a lot for your reply, Keith.
    > >
    > > In the view of C language, the addressese of array elements are always
    > > increased along the index. Which means my way cannot relect the real
    > > order of memony allocation.

    >
    > That (almost certainly) *is* the real order of memory allocation.
    >
    > More precisely, on most hosted systems, C addresses (pointer values)
    > directly correspond to machine-level virtual addresses. (On some
    > embedded systems, C addresses might correspond to machine-level
    > physical addresses.)
    >
    > > At last, you said "(You'd have to compare addresses of distinct
    > > objects, which invokes undefined behavior.)." However, the addresses,
    > > or locations, of the static or local objects are optimized by
    > > compilers, their addresses can tell nothing about the arrangement.
    > >
    > > How about dynamic objects? Can they tell me the order of memory
    > > allocation?

    >
    > Your question is still very unclear. What exactly are you asking
    > about?
    >
    > Whatever your actual question is, the answer is almost certainly that
    > you can't determine it in portable C, and there's almost certainly no
    > good reason why you should care.
    >
    > Objects in C are allocated differently depending on their storage
    > durations. Objects with "static" storage duration exist throughout
    > the execution of the program. Objects with "automatic" storage
    > duration, such as (non-static) local objects in functions, exist
    > during the execution of the block in which they're declared. Objects
    > with "allocated" storage duration are created by malloc(), calloc(),
    > or realloc(), and destroyed by free() or realloc() (is this what you
    > mean by "dynamic objects"?).
    >
    > The language says nothing about the relative addresses of any objects,
    > regardless of their storage durations.
    >
    > Also, please learn to post properly. See
    > <http://cfaj.freeshell.org/google/> and
    > <http://www.caliburn.nl/topposting.html>.
    >
    > --
    > 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.


    Just to add Keith's mail, All the local variables are generally stored
    in the stack during the function call (called by many names as
    'activation record', 'function call record', call stack etc). Where as
    the objects created by malloc/calloc/realloc/new are created in the
    heap memory. Compilers (specifically linker) will place global and
    static variables in data section where they are exist through out the
    program.
    This information can be found when you read the linker document of a
    compiler. Storage allocations are interesting topic by itself :)

    -kondal
    kondal, Sep 13, 2006
    #6
  7. Re: How do we know the memory arrangement using in microprocessors?Top-Bottom or Bottom-Top?

    Cuthbert wrote:
    > Thanks a lot for your reply, Keith.
    >
    > In the view of C language, the addressese of array elements are always
    > increased along the index. Which means my way cannot relect the real
    > order of memony allocation.
    >
    > At last, you said "(You'd have to compare addresses of distinct
    > objects, which invokes undefined behavior.)." However, the addresses,
    > or locations, of the static or local objects are optimized by
    > compilers, their addresses can tell nothing about the arrangement.
    >
    > How about dynamic objects? Can they tell me the order of memory
    > allocation?


    I would look at the documentation for the processor and compiler.

    Why do you need to care btw ?
    =?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=, Sep 13, 2006
    #7
  8. Re: How do we know the memory arrangement using in microprocessors?Top-Bottom or Bottom-Top?

    "kondal" <> writes:
    [...]
    > Just to add Keith's mail, All the local variables are generally stored
    > in the stack during the function call (called by many names as
    > 'activation record', 'function call record', call stack etc. Where as
    > the objects created by malloc/calloc/realloc/new are created in the
    > heap memory. Compilers (specifically linker) will place global and
    > static variables in data section where they are exist through out the
    > program.
    > This information can be found when you read the linker document of a
    > compiler. Storage allocations are interesting topic by itself :)


    None of this is guaranteed by the standard. The language itself does
    not define "stack", "heap", or "data section". Many implementations
    use such things, but not all do.

    --
    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, Sep 13, 2006
    #8
  9. Cuthbert wrote:
    > Hi folks,
    >
    > This question is a little deep into memory management of
    > microprocessor.
    > How do we know the memory arrangement using in microprocessors?
    > Top-Bottom or Bottom-Top?



    Because of the way pointer and array indexing is defined, in C pointer
    arithmetic is always "rightside up". There's probably no way to tell
    anyway, the compiler would have to hide any funny business. For
    example, on the old x86 real-mode segmented architecture, the address
    was kept in two separate parts that had to be non-intuitively merged by
    the compiler anytime you did math on (huge) pointers. Though from the
    user's perspective all you saw was the equivalent of a 64-bit
    "unsigned long int".

    There have been a few computers with "backwards" address arithmetic.
    It turns out to be (slightly) faster to design a subtractor than an
    adder-- A few very old computers, like the old IBM 709x series, used
    subtractive arithmetic when indexing. I don't know of any currently
    running computer that does so though . Perhaps some of those
    super-configurable DSP processors can do this.
    Ancient_Hacker, Sep 13, 2006
    #9
    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. Martinez
    Replies:
    3
    Views:
    413
    Andrey Kuznetsov
    Sep 12, 2006
  2. tedu

    union arrangement

    tedu, Jan 24, 2006, in forum: C Programming
    Replies:
    16
    Views:
    581
    Netocrat
    Jan 30, 2006
  3. all arrangement of a word

    , Jul 7, 2008, in forum: C Programming
    Replies:
    12
    Views:
    503
    Antoninus Twink
    Jul 8, 2008
  4. Bugcy 013

    Python-GUI Button arrangement Help

    Bugcy 013, Feb 16, 2011, in forum: Python
    Replies:
    0
    Views:
    307
    Bugcy 013
    Feb 16, 2011
  5. Ganesh Kumar

    Python GUI Tkinter Button arrangement

    Ganesh Kumar, Feb 16, 2011, in forum: Python
    Replies:
    0
    Views:
    293
    Ganesh Kumar
    Feb 16, 2011
Loading...

Share This Page