where static objects live in memory.

[puzzlecracker]

Dynamically allocated objects reside on a heap, local objects on a
stack. What about static objects?

Thanks

 

[Gianni Mariani]

Dynamically allocated objects reside on a heap, local objects on a
stack. What about static objects?

Same place as globals. Referred to sometimes as "global" memory, or
"global and static" memory.

 

[MAx]

Same place as globals. Referred to sometimes as "global" memory, or
"global and static" memory.

Globas and Statics reside in the Datasegment of the address space.


Thanks
MAx

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Globas and Statics reside in the Datasegment of the address space.

The BSS segment to be more accurate (Data segment can be confused with
the data region which contains the code and constants and is usually
read only).

However C++ does not specify these things, it does not even require that
variables with automatic storage are stored on a stack, the closest it
comes to discussing a stack is the concept of stack unwinding when
exceptions are thrown.

 

[James Kanze]

On 2007-09-14 13:42, MAx wrote:

The BSS segment to be more accurate (Data segment can be confused with
the data region which contains the code and constants and is usually
read only).

It depends very much on the implementation. The name BSS
segment is a Unix'ism, I think: the original Unix on PDP-11 had
three "segments": data, bss and stack. (From what I have heard,
the name bss came from the name of the segment register in the
MMU of the PDP-11.) Basically, the data segment had a fixed
size, the bss segment could grow up, and the stack segment could
grow down. The data segment held the program itself, and all
initialized data; bss was for uninitialized data and dynamically
allocated memory. Very, very quickly, a fourth, write protected
segment, called text, was added for the code (but not for
initialized data, which could be changed during run-time---there
was no const back then).

However C++ does not specify these things, it does not even require that
variables with automatic storage are stored on a stack, the closest it
comes to discussing a stack is the concept of stack unwinding when
exceptions are thrown.

And in fact, I once used a C compiler where the "stack" was
allocated dynamically on the heap: function calls and returns
were a bit expensive (the equivalent of a malloc/free), but
memory use was a lot more flexible. (Not that it mattered. The
machine on which it ran was a mainframe, which was normally
outfitted with over 16 MB, compared to the 64-256 KB which was
current on most machines at the time.)

 

[Jerry Coffin]

[ ... ]

It depends very much on the implementation. The name BSS
segment is a Unix'ism, I think: the original Unix on PDP-11 had
three "segments": data, bss and stack. (From what I have heard,
the name bss came from the name of the segment register in the
MMU of the PDP-11.)

The name predates Unix by a fair amount. AFAIK, it originated on IBM
mainframes.

[ ... ]

And in fact, I once used a C compiler where the "stack" was
allocated dynamically on the heap: function calls and returns
were a bit expensive (the equivalent of a malloc/free), but
memory use was a lot more flexible. (Not that it mattered. The
machine on which it ran was a mainframe, which was normally
outfitted with over 16 MB, compared to the 64-256 KB which was
current on most machines at the time.)

Sounds some of those same IBM mainframes.

 

[James Kanze]

[ ... ]

It depends very much on the implementation. The name BSS
segment is a Unix'ism, I think: the original Unix on PDP-11 had
three "segments": data, bss and stack. (From what I have heard,
the name bss came from the name of the segment register in the
MMU of the PDP-11.)

The name predates Unix by a fair amount. AFAIK, it originated on IBM
mainframes.

Interesting. As I said, I remember hearing it. I don't
remember where, or from whom, so I have no idea as to the
reliability of my source. (But it wasn't anything official.)

[ ... ]

And in fact, I once used a C compiler where the "stack" was
allocated dynamically on the heap: function calls and returns
were a bit expensive (the equivalent of a malloc/free), but
memory use was a lot more flexible. (Not that it mattered. The
machine on which it ran was a mainframe, which was normally
outfitted with over 16 MB, compared to the 64-256 KB which was
current on most machines at the time.)

Sounds some of those same IBM mainframes.

Siemens mainframes. The instruction set of which was more or
less IBM mainframe compatible, at least in user mode.

 

[Pete Becker]

[ ... ]

It depends very much on the implementation. The name BSS
segment is a Unix'ism, I think: the original Unix on PDP-11 had
three "segments": data, bss and stack. (From what I have heard,
the name bss came from the name of the segment register in the
MMU of the PDP-11.)

The name predates Unix by a fair amount. AFAIK, it originated on IBM
mainframes.

Interesting. As I said, I remember hearing it. I don't
remember where, or from whom, so I have no idea as to the
reliability of my source. (But it wasn't anything official.)

For what it's worth, my understanding (from the late 60s) is that BSS
is an acronym, standing for Block Starting Symbol, that is, a block of
memory associated with a symbolic name that refers to the first
location in the block. There's also BES, for Block Ending Symbol, where
the symbolic name refers to the end of the block (I don't remember
whether it's the last location in the block or the first one after the
block).