where does system stack grow in cpp?

[puzzlecracker]

Guys -

Is it possible to find which way system stack grows? Perhaps, I am
not precise enough: When a function is called, the return address of
(callee) function is put on the stack. Thus, the question is the
direction where that stack heading (address increasing or decreasing).
How would you implement this in cpp?

any suggestion.

[David White]

puzzlecracker wrote:

Guys -

Is it possible to find which way system stack grows? Perhaps, I am
not precise enough: When a function is called, the return address of
(callee) function is put on the stack. Thus, the question is the
direction where that stack heading (address increasing or decreasing).
How would you implement this in cpp?

any suggestion.

Just call a function that takes a parameter, take the address of the
parameter, then call another function that takes a parameter and take the
address of that parameter. Print out the addresses and you'll see in which
direction they are heading.

DW

[David White]

David White wrote:

puzzlecracker wrote:

Guys -

Is it possible to find which way system stack grows? Perhaps, I am
not precise enough: When a function is called, the return address of
(callee) function is put on the stack. Thus, the question is the
direction where that stack heading (address increasing or
decreasing). How would you implement this in cpp?

any suggestion.
Just call a function that takes a parameter, take the address of the
parameter, then call another function

from within the first function
that takes a parameter and take
the address of that parameter. Print out the addresses and you'll see
in which direction they are heading.

DW

[puzzlecracker]

David White wrote:

puzzlecracker wrote:

Guys -

Is it possible to find which way system stack grows? Perhaps, I am
not precise enough: When a function is called, the return address of
(callee) function is put on the stack. Thus, the question is the
direction where that stack heading (address increasing or decreasing).
How would you implement this in cpp?

any suggestion.

Just call a function that takes a parameter, take the address of the
parameter, then call another function that takes a parameter and take the
address of that parameter. Print out the addresses and you'll see in which
direction they are heading.

DW

That will NOT work.
you can pass either by value or by reference (by pointer is the same in
the given context).

If pass by value - taking it address will return the address in the
current frame even if you pass it to function - and the value is copied
to the function's frame. Likewise, passing it by referenfce will not
show the difference.

[Mike Wahler]

"puzzlecracker" <ir*********@gmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

Guys -

Is it possible to find which way system stack grows?
Not with standard C++. The language makes no requirement
that a 'system stack' or 'stack' exists at all.
Perhaps, I am
not precise enough: When a function is called, the return address of
(callee) function is put on the stack. Thus, the question is the
direction where that stack heading (address increasing or decreasing).
How would you implement this in cpp?

Can't be done. Perhaps you could find out by consulting
documentation of your platform.

-Mike

[Alf P. Steinbach]

* puzzlecracker:

* David White:

Just call a function that takes a parameter, take the address of the
parameter, then call another function that takes a parameter and take the
address of that parameter. Print out the addresses and you'll see in which
direction they are heading.

That will NOT work.

Works fine in practice. Instead of a parameter you can use a local variable.
It's the same. Of course there are numerous theoretical reasons why it might
not work, such as (1) you declared the parameters/variables as 'register', and
your code won't compile, or (2) you declared the functions as 'fastcall' or
some such using compiler-specific directives, or (3) you're using a C++
implementation that allocates everything dynamically -- I think there's an
interpreter somewhere (quincy?) that does that... Anyway, when you know that
you don't know much about some aspect, it's a good idea to try out things.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[David White]

puzzlecracker wrote:

David White wrote:

Just call a function that takes a parameter, take the address of the
parameter, then call another function that takes a parameter and
take the address of that parameter. Print out the addresses and
you'll see in which direction they are heading.

DW
That will NOT work.

I think it will. Try it.
you can pass either by value
I meant by value.
or by reference (by pointer is the same
in the given context).

If pass by value - taking it address will return the address in the
current frame even if you pass it to function - and the value is
copied to the function's frame.

And what I suggested was to take the address of the parameter _as received
by the function_, i.e., after a copy of the argument is pushed onto the
stack. Or use local variables as APS suggested. Two or more nested calls
will reveal the direction in which the stack is growing.

DW

[puzzlecracker]

Alf P. Steinbach wrote:

* puzzlecracker:

* David White:

Just call a function that takes a parameter, take the address of the
parameter, then call another function that takes a parameter and take the
address of that parameter. Print out the addresses and you'll see in which
direction they are heading.

That will NOT work.

Works fine in practice. Instead of a parameter you can use a local variable.
It's the same. Of course there are numerous theoretical reasons why it might
not work, such as (1) you declared the parameters/variables as 'register', and
your code won't compile, or (2) you declared the functions as 'fastcall' or
some such using compiler-specific directives, or (3) you're using a C++
implementation that allocates everything dynamically -- I think there's an
interpreter somewhere (quincy?) that does that... Anyway, when you know that
you don't know much about some aspect, it's a good idea to try out things.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

everyone is macking such radical claims:

I am thinking to determing this we can do something along these line
(CODE IS LEGAL IN standard c++ - which isn't concerned with stacks
grow but with its determination)

include<iostream>

int * function(){ int b; return &b; }

int main (){

int a;
long diff=static_cast<long>(&a -function());
if(diff<=0)
std::cout<<"grows up\n";
else
std::cout<<"grows down\n";

}

this will work given that above function() will NOT be inlined.

By the way, is there a directive to forcefully prohibit a compiler
from inlining?

[David White]

puzzlecracker wrote:

everyone is macking such radical claims:
Radical?
I am thinking to determing this we can do something along these line
(CODE IS LEGAL IN standard c++ - which isn't concerned with stacks
grow but with its determination)

include<iostream>

int * function(){ int b; return &b; }

int main (){

int a;
long diff=static_cast<long>(&a -function());
if(diff<=0)
std::cout<<"grows up\n";
else
std::cout<<"grows down\n";

}

this will work given that above function() will NOT be inlined.
This is just another form of what was suggested in the previous replies.
By the way, is there a directive to forcefully prohibit a compiler
from inlining?

Not in the language standard. Check your compiler's documentation.

DW

[EventHelix.com]

This is dependent on the processor architecture. The code generator for
your C++ compiler would be using the stack organization that is
supported by the compiler.

For example, on the 68000 processor a push is a predecrement on the
stack pointer while the op is a post increment. Thus the stack grows by
decreasing the address. The following article describes this:

http://www.eventhelix.com/RealtimeMa...ranslation.htm

--
EventStudio System Designer 2.5 - http://www.EventHelix.com/EventStudio
Sequence Diagram Based System Design and Object Modeling Tool

[Rolf Magnus]

Alf P. Steinbach wrote:

Of course there are numerous theoretical reasons why it might not work,
such as (1) you declared the parameters/variables as 'register', and your
code won't compile, or (2) you declared the functions as 'fastcall' or
some such using compiler-specific directives, or (3) you're using a C++
implementation that allocates everything dynamically
or (4) the compiler puts the parameters in registers by default or (5) the
function gets inlined, ...
Anyway, when you know that you don't know much about some aspect, it's a
good idea to try out things.

It's an even better idea to consult the manual of the platform/CPU if you
want to know how it works. There is a lot of code out there that is based
on false assumptions because people tried things out instead of RingTFM,
especially in the C++ area. And then, when they want to port it, they think
the compiler is broken, because the code won't work anymore.

[Mirek Fidler]

EventHelix.com wrote:

This is dependent on the processor architecture. The code generator for
your C++ compiler would be using the stack organization that is
supported by the compiler.

For example, on the 68000 processor a push is a predecrement on the
stack pointer while the op is a post increment. Thus the stack grows by
decreasing the address. The following article describes this:

Actually, I think that all architectures have stack growing down today.

Mirek

[puzzlecracker]

Mirek Fidler wrote:

EventHelix.com wrote:

This is dependent on the processor architecture. The code generator for
your C++ compiler would be using the stack organization that is
supported by the compiler.

For example, on the 68000 processor a push is a predecrement on the
stack pointer while the op is a post increment. Thus the stack grows by
decreasing the address. The following article describes this:

Actually, I think that all architectures have stack growing down today.

Mirek

MYy question is how to determine it programatically?

[Kai-Uwe Bux]

puzzlecracker wrote:

Mirek Fidler wrote:

[snip]

Actually, I think that all architectures have stack growing down today.

Mirek

MYy question is how to determine it programatically?

Well, if M. Fidler is correct, then the following code will do:

#include <iostream>

int main ( void ) {
std::cout << "stack grows down.\n";
}
Best

Kai-Uwe Bux

[E. Robert Tisdale]

puzzlecracker wrote:

Is it possible to find which way system stack grows?
Perhaps, I am not precise enough: When a function is called,
the return address of (callee) function is put on the stack.
Thus, the question is the direction where that stack heading
(address increasing or decreasing).
How would you implement this in cpp? cat main.cpp #include <iostream>

unsigned int factorial(unsigned int n) {
std::cerr << n << ": " << &n << std::endl;
return (1 < n)? n*factorial(n - 1): 1;
}

int main(int argc, char* argv[]) {
std::cout << "5! = " << factorial(5) << std::endl;
return 0;
}
g++ -Wall -ansi -pedantic -o main main.cpp
./main 5: 0xbf9f6210
4: 0xbf9f61f0
3: 0xbf9f61d0
2: 0xbf9f61b0
1: 0xbf9f6190
5! = 120 grep 'model name' /proc/cpuinfo

model name : Pentium III (Katmai)

Evidently, my program stack grows "upward"
from the "bottom" of [virtual] memory (0xffffffff)
toward the "top" of [virtual] memory (0x00000000).

[Mirek Fidler]

puzzlecracker wrote:

Mirek Fidler wrote:

EventHelix.com wrote:

This is dependent on the processor architecture. The code generator for
your C++ compiler would be using the stack organization that is
supported by the compiler.

For example, on the 68000 processor a push is a predecrement on the
stack pointer while the op is a post increment. Thus the stack grows by
decreasing the address. The following article describes this:

Actually, I think that all architectures have stack growing down today.

Mirek

MYy question is how to determine it programatically?

No portable way. You know, machine does not have stack at all and still
have C++ implementation. Or it can have more stacks. Or whatever.

Mirek

[Ron Natalie]

Mirek Fidler wrote:

No portable way. You know, machine does not have stack at all and still
have C++ implementation. Or it can have more stacks. Or whatever.

When I worked on the HEP, our "stack" was indeed a linked list.

[puzzlecracker]

Ron Natalie wrote:

Mirek Fidler wrote:

No portable way. You know, machine does not have stack at all and still
have C++ implementation. Or it can have more stacks. Or whatever.

When I worked on the HEP, our "stack" was indeed a linked list.

I don't see why there is a such controversy about machine/compiler
dependency in respect to system stack. Yet, a rather trivial matter is
overlooked. Stack - by definition- can either grow upwards or
downwards(pushing from the top or bottom). Correct?

In C++/C function return address is push onto to the stack (who cares
how stack is implemented) - making it most top element of the stack
(abstractly speaking). Calling the next function from within called
function would add called function address to the top of the stack, and
so on. That address can either increase or decrease - it will not be
the same (if it is the same: rm -rf compiler folder and guillotine
everyone in the group who developed it).
Again, where is the problem?

[David White]

puzzlecracker wrote:

I don't see why there is a such controversy about machine/compiler
dependency in respect to system stack. Yet, a rather trivial matter is
overlooked. Stack - by definition- can either grow upwards or
downwards(pushing from the top or bottom). Correct?
I think there are some crossed wires here. You are talking about the way a
typical compiler generates code on a given machine so that a C++ program
will behave as the standard specifes. As others have pointed out, the
standard makes no mention of stacks. It just talks about function calls,
variables defined in various scopes etc. It's up to the compiler to make the
program behave correctly, in whatever way it chooses.
In C++/C function return address is push onto to the stack (who cares
how stack is implemented)
That's how a compiler usually chooses to do it, anyway.
- making it most top element of the stack
(abstractly speaking). Calling the next function from within called
function would add called function address to the top of the stack,
and so on. That address can either increase or decrease - it will not
be the same (if it is the same: rm -rf compiler folder and guillotine
everyone in the group who developed it).
Again, where is the problem?

No problem, but you are not talking about the C++ language. You are talking
about specific implementations. Strictly speaking, this whole thread is
off-topic.

DW

[GB]

E. Robert Tisdale wrote:

#include <iostream>

unsigned int factorial(unsigned int n) {
std::cerr << n << ": " << &n << std::endl;
return (1 < n)? n*factorial(n - 1): 1;
}

int main(int argc, char* argv[]) {
std::cout << "5! = " << factorial(5) << std::endl;
return 0;
}

> g++ -Wall -ansi -pedantic -o main main.cpp
> ./main 5: 0xbf9f6210
4: 0xbf9f61f0
3: 0xbf9f61d0
2: 0xbf9f61b0
1: 0xbf9f6190
5! = 120

> grep 'model name' /proc/cpuinfo

model name : Pentium III (Katmai)

Evidently, my program stack grows "upward"

According to your output, your stack grows downward (i.e., decreasing
addresses), not upward. The (virtual) addresses you printed are
decreasing with increased level of nesting (1 being the deepest nesting).
from the "bottom" of [virtual] memory (0xffffffff)
toward the "top" of [virtual] memory (0x00000000).

In what sense would 0xffffffff be the "bottom" of a presumably 32-bit
virtual memory space?

Gregg

[David White]

GB wrote:

E. Robert Tisdale wrote:

Evidently, my program stack grows "upward"

According to your output, your stack grows downward (i.e., decreasing
addresses), not upward. The (virtual) addresses you printed are
decreasing with increased level of nesting (1 being the deepest
nesting).

> from the "bottom" of [virtual] memory (0xffffffff)
> toward the "top" of [virtual] memory (0x00000000).

In what sense would 0xffffffff be the "bottom" of a presumably 32-bit
virtual memory space?

Well, if you print out a block of memory from address zero it is likely that
the addresses will increase from the top of the page to the bottom, which
makes address zero the "top". However, I thought the convention was to call
zero the bottom and 0xffff.... the top.

DW

[Jack Klein]

On Thu, 06 Oct 2005 21:17:57 +0200, Mirek Fidler <cx*@volny.cz> wrote
in comp.lang.c++:

EventHelix.com wrote:

This is dependent on the processor architecture. The code generator for
your C++ compiler would be using the stack organization that is
supported by the compiler.

For example, on the 68000 processor a push is a predecrement on the
stack pointer while the op is a post increment. Thus the stack grows by
decreasing the address. The following article describes this:

Actually, I think that all architectures have stack growing down today.

You're wrong to think that. There are some architectures (ARM, for
one), where you can choose the stack direction at compile time. Of
course, all source and libraries combined into a single executable
must be built with the same choice.

There are also some architectures (again including ARM), where you can
select big or little endian orientation.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html