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

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[i]);

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
$

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

"Cuthbert" <cuthbert.kao@gmail.com> 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[i]);
>
> 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[i]);

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[i] < &var[i+1]) {
printf("&var[%d] < &var[%d]\n", i, i+1);
}
else if (&var[i] == &var[i+1]) {
printf("&var[%d] == &var[%d] (?)\n", i, i+1);
}
else if (&var[i] > &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) 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.

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

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" <cuthbert.kao@gmail.com> writes:
> > This question is a little deep into memory management of
......................

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

"Cuthbert" <cuthbert.kao@gmail.com> 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) 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.

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

Keith Thompson wrote:
> "Cuthbert" <cuthbert.kao@gmail.com> 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) 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.

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

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

Keith Thompson wrote:
> "Cuthbert" <cuthbert.kao@gmail.com> 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) 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.

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

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 ?

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

"kondal" <kondal04@gmail.com> 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) 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.

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

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.