where variables are stored?

[Neo]

Where does global, static, local, register variables, free memory and C
Program instructions get stored?

-Neo

 

[dandelion]

Where does global, static, local, register variables, free memory and C
Program instructions get stored?

Depends largely on your compiler/OS.

Locals are usually stored on stack or registers, global initialized data in
some '.data' segment, uninitialized data in the '.bss' segment. But that's a
mere "grosso modo" answer, since there is no generally valid one.

Your compiler may store it in different segments, but the idea will be
pretty much the same.

 

[CBFalconer]

Where does global, static, local, register variables, free memory
and C Program instructions get stored?

It doesn't matter, so long as those entities behave as specified in
the standard. Elves can scratch notes on little bitty pieces of
paper and pass them to other elves for reading, as far as you know.

 

[James McIninch]

<posted & mailed>

Where does global, static, local, register variables, free memory and C
Program instructions get stored?

That's at the disgression of the compiler / operating environment. C doesn't
require you to need to know that.

 

[Gregory K Johnson]

Elves can scratch notes on little bitty pieces of

paper and pass them to other elves for reading

Little known fact: the Elvish tongue associated this implementation
technique (known as the "Executable and Linking Format" by those who
wish to disguise its true etymology) is actually fairly common.

 

[E. Robert Tisdale]

Where does global, static, local, register variables, free memory
and [machine] instructions get stored?

It is implementation dependent.
In the *typical implementation*,
you can think of *virtual memory* (vm) as a sequence of addresses

00000000 top
00000001
00000002
.
.
.
FFFFFFFE
FFFFFFFF bottom

The text (code) segment begins near the top of vm
and is followed by the data segment which may reserve storage
for static and global constants and variables.
The program stack (automatic storage)
extends upward from somewhere near the bottom of vm
contains local variable.
The program stack grows upward into *free storage*.
The free storage above the program stack can be allocated
dynamically using a *free list*.

Consult the documentation for your C compiler,
operating system and machine architecture for details
about your implementation.

 

[Thomas Matthews]

Where does global, static, local, register variables, free memory and C
Program instructions get stored?

-Neo

Variables, locations that can be modified, must be
stored somewhere where they can be modified: harddrive,
RAM, at a friend's house.

Constants can be placed at locations that are either
read-only or read/write, such as CDROMs, PROMS, RAM,
etc.

The exact location is determined by your compiler,
operating system and platform.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

 

[Mike Wahler]

Where does global, static, local, register variables, free memory and C
Program instructions get stored?

Somewhere. The language does not specify this.

However, qualifying a declaration with 'register'
comprises a *request* for the compiler to store
an object in a register (in the interest of
'optimization'). But this request need not be
honored (and is rarely needed, since a good compiler
is typically much better at optimization that a mere human).

-Mike

 

[Keith Thompson]

Somewhere. The language does not specify this.

However, qualifying a declaration with 'register'
comprises a *request* for the compiler to store
an object in a register (in the interest of
'optimization'). But this request need not be
honored (and is rarely needed, since a good compiler
is typically much better at optimization that a mere human).

The standard doesn't even suggest that it be stored in a register
(though as the word implies that, or ignoring it, is probably the most
common behavior). The actual wording (C99 6.7.1p4) is:

A declaration of an identifier for an object with storage-class
specifier register suggests that access to the object be as fast
as possible. The extent to which such suggestions are effective is
implementation-defined.

 

[Richard Tobin]

Where does global, static, local, register variables, free memory
and C Program instructions get stored?

[/QUOTE]

It doesn't matter, so long as those entities behave as specified in
the standard.

However, the standard is motivated by the usual implementations of
the various kinds of memory. Why would it bother to prevent you
accessing variables after function return if it didn't intend that
they be put on a stack? Why would register variables be so-called
if there were no implication that they might go in registers?

Like most specifications, the C standard is much easier to understand
if you know the motivation for it, and:

Elves can scratch notes on little bitty pieces of
paper and pass them to other elves for reading, as far as you know.

.... is obviously not what the standardizers had in mind.

-- Richard

 

[Mike Wahler]

It doesn't matter, so long as those entities behave as specified in
the standard.

However, the standard is motivated by the usual implementations of
the various kinds of memory. Why would it bother to prevent you
accessing variables after function return if it didn't intend that
they be put on a stack? Why would register variables be so-called
if there were no implication that they might go in registers?

Like most specifications, the C standard is much easier to understand
if you know the motivation for it, and:

Elves can scratch notes on little bitty pieces of
paper and pass them to other elves for reading, as far as you know.

... is obviously not what the standardizers had in mind.[/QUOTE]

IMO what they had in mind was to keep these things abstract,
and to let implementations define the actual mechanics,
so that they can best take advantage of the host platform
(this includes implementation designs which have yet to be
concieved).

-Mike

 

[E. Robert Tisdale]

IMO what they had in mind was to keep these things abstract,
and to let implementations define the actual mechanics,
so that they can best take advantage of the host platform
(this includes implementation designs
which have yet to be concieved).

That is correct.
But "the standardizers" must also prove that
an implementation of those abstractions is feasible.
They must be able to describe a "typical implementation".

The typical implementation is also a pedagogical tool
that instructors can use to demystify the function of compilers
and comfort skeptical students of the C programming language.
In this case, the typical implementation need not be
the usual implementation or even an actual implementation
but merely a plausible implementation that can demonstrate
to the student that some implementation is possible.