Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > about memory model

Reply
Thread Tools

about memory model

 
 
Szabolcs Borsanyi
Guest
Posts: n/a
 
      05-26-2008
On Mon, May 26, 2008 at 11:23:02AM +0100, Flash Gordon wrote:
> Szabolcs Borsanyi wrote, On 26/05/08 10:18:
>>
>> The concept of stack is not part of the language, but variables with
>> automatic storage (local variables without the static keyword) are
>> stored by most systems on some sort of stack. The global variables

>
> On a lot of systems at least some of them are stored in registers and
> never written to if the compiler can avoid it.
>


Thanks, you are right, indeed. Optimising compilers use registers extensively,
unless the address of the variable is asked for. (Or could they use registers
even then?...)

> <snip>
>
>> The qualifiers (e.g. const, volatile) do not affect the storage, but they
>> do have an impact on the access to those variables.

>
> Incorrect. On a lot of systems const will cause "variables" to be stored
> in some form of read-only memory, either actual ROM or a page that the
> OS will mark as read only when it loads the program.


Thank you for correcting me.
I wonder if the volatile qualifier could have an impact on the way of storage...

Szabolcs
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      05-26-2008
"Malcolm McLean" <(E-Mail Removed)> writes:
> "Jack Klein" <(E-Mail Removed)> wrote in message
>> There are, of course, several platforms where this is just plain
>> completely incorrect.
>>

> The OP wants an explanation of how C's memory is laid out, not a
> formal definition of the memory model.


And you gave him an explanation of how *some* C implementations do it.

It's important to understand the distinction between the language and
an implementation of the language. Please don't blur that
distinction.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      05-26-2008
Szabolcs Borsanyi wrote, On 26/05/08 20:34:
> On Mon, May 26, 2008 at 11:23:02AM +0100, Flash Gordon wrote:
>> Szabolcs Borsanyi wrote, On 26/05/08 10:18:
>>> The concept of stack is not part of the language, but variables with
>>> automatic storage (local variables without the static keyword) are
>>> stored by most systems on some sort of stack. The global variables

>> On a lot of systems at least some of them are stored in registers and
>> never written to if the compiler can avoid it.

>
> Thanks, you are right, indeed. Optimising compilers use registers extensively,
> unless the address of the variable is asked for. (Or could they use registers
> even then?...)


If it is not declared volatile the compiler may be able to keep it in a
register for long stretches of code, an easy example being any stretch
of code where no pointers are used.

>>> The qualifiers (e.g. const, volatile) do not affect the storage, but they
>>> do have an impact on the access to those variables.

>> Incorrect. On a lot of systems const will cause "variables" to be stored
>> in some form of read-only memory, either actual ROM or a page that the
>> OS will mark as read only when it loads the program.

>
> Thank you for correcting me.
> I wonder if the volatile qualifier could have an impact on the way of storage...


That's easy. If the variable is declared volatile const rather than just
const is may well *not* me placed in read-only memory
--
Flash Gordon
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      05-26-2008
Keith Thompson wrote, On 26/05/08 19:21:
> Flash Gordon <(E-Mail Removed)> writes:
>> Szabolcs Borsanyi wrote, On 26/05/08 10:18:

> [...]
>>> The qualifiers (e.g. const, volatile) do not affect the storage, but they
>>> do have an impact on the access to those variables.

>> Incorrect. On a lot of systems const will cause "variables" to be
>> stored in some form of read-only memory, either actual ROM or a page
>> that the OS will mark as read only when it loads the program.

> [...]
>
> That can happen only if the initial value can be determined at
> compilation time.


True.

> For that matter, if an object's initial value can be determined at
> compilation time and the compiler can determine that it's never
> modified, the compiler is free to store it in ROM even if it's not
> declared const (though in that case it *should* have been declared
> const).


True, but rather harder for the implementation to prove where there are
multiple compilation units. I know for definite of one compiler for
embedded systems which puts all const qualified variable with static
storage duration in a seperate memory section specifically so that you
can allocate it to ROM but it does not put non-const qualified variables
in that section even if they are never modified. I suspect (without
proof) that this is probably quite common.
--
Flash Gordon
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      05-26-2008
>On Mon, May 26, 2008 at 11:23:02AM +0100, Flash Gordon wrote:
>>On a lot of systems at least some [local variables] are stored
>>in registers and never written to if the compiler can avoid it.


In article <(E-Mail Removed) .uk>
Szabolcs Borsanyi <(E-Mail Removed)> wrote:
>Thanks, you are right, indeed. Optimising compilers use registers
>extensively, unless the address of the variable is asked for. (Or
>could they use registers even then?...)


They could, although exactly how depends on both the compiler and
the target architecture. Consider, e.g., the following C code
fragment:

for (i = 0; i < n; i++)
do_something(i);
maybe_alter(&i);
if (i != n)
do_something_else();
for (i = 0; i < n; i++)
do_third_thing(i);

Here, "i" is a likely candidate for "register-ization" to make
the two loops run faster. In between the two loops, however, we
pass &i to a function that might change it.

A reasonably clever compiler could easily rewrite this as:

for (i1 = 0; i1 < n; i1++)
do_something(i1);
i2 = i1;
maybe_alter(&i2);
if (i2 != n)
do_something_else();
for (i3 = 0; i3 < n; i3++)
do_third_thing(i3);
i2 = i3; /* if needed -- actually "i4" (if i is used below) */

It is now clear that i1 and i3 can be stored in a machine register
(the same machine register, in fact) even if i2 must live in RAM.

If the CPU has the ability to take the address of a register --
this is rare these days but was not uncommon once, and could perhaps
become popular again someday -- one need not even rewrite the
variable names to make this optimization possible.

>I wonder if the volatile qualifier could have an impact on the
>way of storage...


Yes, it often does. (In fact, cases where it fails to prevent
"registerization" tend to be compiler bugs. These bugs do happen
though.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Convert Java Model to Java Model without XML erinbot@gmail.com Java 1 10-06-2006 09:00 PM
Java 1.4 memory model and hyper threading usenet@kikobu.com Java 2 10-03-2006 02:01 AM
Some quick c++ memory-model concerns... Chris Thomasson C++ 0 09-03-2006 02:22 PM
Differences between Sony Memory Stick & memory Stick Pro vs Memory Stick Duo? zxcvar Digital Photography 3 11-28-2004 10:48 PM
Plz send me some good online link for memory model in C PKJ C++ 1 10-22-2004 01:20 AM



Advertisments