«

I have always indirectly know how RAM is used when a C++ program is
run, but I wanted to be sure I got it right:

First the OS copies the whole program to RAM. Every statement of the
kind int x; would make the OS to look for free RAM to storage the value
of x. Every statement like cout << something would cause the OS to
store "something" in RAM so it can be outputed. The OS is ready to free
memory as it moves outside the scope of variables.

So when a program says it has a minimun requirement of X RAM it means
that the most RAM used at any given time is never more than X.

Is this an accurate picture?

Gaijinco wrote:
> I have always indirectly know how RAM is used when a C++ program is
> run, but I wanted to be sure I got it right:
>
It depends on your target platform there is nothing in the C++ standard
concerning RAM or it's use.

> First the OS copies the whole program to RAM. Every statement of the
> kind int x; would make the OS to look for free RAM to storage the value
> of x. Every statement like cout << something would cause the OS to
> store "something" in RAM so it can be outputed. The OS is ready to free
> memory as it moves outside the scope of variables.
>
You'd be better asking on a newsgroup for your OS, but the above isn't a
very good description of any environment I know...

> So when a program says it has a minimun requirement of X RAM it means
> that the most RAM used at any given time is never more than X.
>
Probably.

--
Ian Collins.

Gaijinco wrote:
> I have always indirectly know how RAM is used when a C++ program is
> run, but I wanted to be sure I got it right:
>
> First the OS copies the whole program to RAM. Every statement of the
> kind int x; would make the OS to look for free RAM to storage the value
> of x.

Not really. The statement

int x;

allocates memory for x either from static memory or stack memory. See
below for more explanations.

> Every statement like cout << something would cause the OS to
> store "something" in RAM so it can be outputed.

When you have a statement such as:

cout << x;

You are calling an overloaded operator to do the output for you. You
know that either the value or the address of x is copied to the stack
frame of the routine (operator <<) being invoked. What the routine does
is up to the implementation. Usually, the routine converts the value of
x to a text string and sends the string to the OS for output.

> The OS is ready to free
> memory as it moves outside the scope of variables.

The OS does not free memory for you. Your program frees memory for
itself. That said, when your program frees a piece of dynamic memory, it
typically does request the OS to "unplug" the memory from the program's
memory space. See below for details.

>
> So when a program says it has a minimun requirement of X RAM it means
> that the most RAM used at any given time is never more than X.
>
> Is this an accurate picture?
>

Forget about what you said. C++ basically deals with 3 kinds of memory:
static memory, stack memory, and dynamic memory.

Static memory is used to store global variables, static variables and
some constants. They can be used through out the program. This memory is
typically part of the program image so it is loaded along with the
program because the compiler always know the exact size of this piece of
memory. In addition, they are loaded to a different segment than the
program texts.

Stack memory is used to store local variables and data necessary to
facilitate function invocation (such as arguments, return address and
return value.) All local variables are deallocated in the reverse order
of allocation once they are out of scope. This memory is usually not
part of the on-disk program image and is created by the OS when the
program is loaded into RAM. Typically, this memory is loaded to the
stack segment with a fixed size. The stack memory is usually large
enough for most operations, but you can overflow it if not careful.

Dynamic memory is used to store "free-store" variables, such as those
created by operator new. The dynamic memory is not part of the program
image, nor is it allocated at load time. Rather, it is brought into the
program's memory space by the OS upon runtime requests (such as calling
operator new().)

For example consider the following program under a typical
implementation and platform:

int a = 1;

int main(void)
{
int b = 2;
int* c = new int(3);

delete c;
}

The global variable a is allocated statically. b is allocated in main's
stack frame when the flow of control enters main. The pointer c is also
allocated in main's stack frame, but the content it points to is
allocated in the dynamic memory by operator new.

If you wish to know more you should consider reading on assembly
language because that's the language that explains all of the memory
arrangements.

Regards,
Ben

On Tue, 07 Feb 2006 13:43:54 +1100, benben <>
wrote:
>If you wish to know more you should consider reading on assembly
>language because that's the language that explains all of the memory
>arrangements.
>
>Regards,
>Ben

Well done. Kudos to you sir.

That was a "blast from the past." And that's a Good Thing.

"People who never get carried away should be." - Malcolm Forbes

Thanks a lot for the information!

> Stack memory is used to store local variables and data necessary to
> facilitate function invocation (such as arguments, return address and
> return value.) All local variables are deallocated in the reverse order
> of allocation once they are out of scope. This memory is usually not
> part of the on-disk program image and is created by the OS when the
> program is loaded into RAM. Typically, this memory is loaded to the
> stack segment with a fixed size. The stack memory is usually large
> enough for most operations, but you can overflow it if not careful.

Do you mean that Stack Memory is always given the same size or is just
calculated once the program is compiled?

By overflowing you mean something like creating a class like:

class Person{
char name[1000];
char last_name[1000];
int telephone[1000];
};

and then creating with a loop 1'000.000 Person objects?

Also, and to be sure I understood you right, Static, Stack and Dynamic
Memory are part of the RAM, right? So there's no chance of trying to
write to L1 or L2 cache without Assembler?

Gaijinco wrote:
>>Stack memory is used to store local variables and data necessary to
>>facilitate function invocation (such as arguments, return address and
>>return value.) All local variables are deallocated in the reverse order
>>of allocation once they are out of scope. This memory is usually not
>>part of the on-disk program image and is created by the OS when the
>>program is loaded into RAM. Typically, this memory is loaded to the
>>stack segment with a fixed size. The stack memory is usually large
>>enough for most operations, but you can overflow it if not careful.
>
>
> Do you mean that Stack Memory is always given the same size or is just
> calculated once the program is compiled?
>
Stack size (assuming a stack) is (typicaly) determined by the operating
environment, not the application.

> By overflowing you mean something like creating a class like:
>
> class Person{
> char name[1000];
> char last_name[1000];
> int telephone[1000];
> };
>
> and then creating with a loop 1'000.000 Person objects?
>
Yes, if a stack has finite size, it can be overflowed.

> Also, and to be sure I understood you right, Static, Stack and Dynamic
> Memory are part of the RAM, right? So there's no chance of trying to
> write to L1 or L2 cache without Assembler?
>
Who said anything about a cache? This is totally implementation specific.

--
Ian Collins.

> Do you mean that Stack Memory is always given the same size or is just
> calculated once the program is compiled?

It really depends on your compiler/linker and your operating system.
Note that the maximum stack size is extremely difficult, if not
impossible, to calculate. Usually your compiler/linker/OS would give a
size good for the majority of applications.

For example, on Windows each program gets 4Mb of stack memory, although
there are APIs to up-size it.

>
> By overflowing you mean something like creating a class like:
>
> class Person{
> char name[1000];
> char last_name[1000];
> int telephone[1000];
> };
>
> and then creating with a loop 1'000.000 Person objects?

A size and a loop doesn't take up much stack space. This is because the
local objects within the loop are deallocated every iteration.

That said, you can easily overflow your stack in two ways:

1. Huge local array.
2. Recursive calls.

(Note: more effective if the above two are combined.)

>
> Also, and to be sure I understood you right, Static, Stack and Dynamic
> Memory are part of the RAM, right? So there's no chance of trying to
> write to L1 or L2 cache without Assembler?
>

They are all "memory", which means Primary Memory, which means memory
that the CPU can directly access and operate on. Whether it includes
anything else is up to the context.

Yes you need an assembler to do low-level coding like writing to CPU
cache and I/O.

Regards,
Ben

benben wrote:
> <somebody else>
>> Also, and to be sure I understood you right, Static, Stack and Dynamic
>> Memory are part of the RAM, right? So there's no chance of trying to
>> write to L1 or L2 cache without Assembler?
>>
>
> They are all "memory", which means Primary Memory, which means memory
> that the CPU can directly access and operate on. Whether it includes
> anything else is up to the context.
>
> Yes you need an assembler to do low-level coding like writing to CPU
> cache and I/O.

Can you write directly to cache? Hardcore

That you need assembler to write to write to IO is surely misleading.
I've used C to access (memory mapped) IO directly on at least 3
microcontrollers (8051, C167, TriCore).

You would need an assembler to write directly to specific CPU registers,
but that doesn't stop the C compiler taking your code and organising
what should go in what specific register.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

> Can you write directly to cache? Hardcore

Some hardware do have software layers.

>
> That you need assembler to write to write to IO is surely misleading.
> I've used C to access (memory mapped) IO directly on at least 3
> microcontrollers (8051, C167, TriCore).

Otherwise you need specific CPU instruction and interrupt handling.

>
> You would need an assembler to write directly to specific CPU registers,
> but that doesn't stop the C compiler taking your code and organising
> what should go in what specific register.

....But not in control of the programmer.

>
> Ben Pope

Regards,
Ben