Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #18846 > unrolled thread

addresses of variables

Back to article view | Back to comp.lang.c

Contents

  addresses of variables Zero <chefmuetze@web.de> - 2012-03-18 03:56 -0700
    Re: addresses of variables "BartC" <bc@freeuk.com> - 2012-03-18 11:18 +0000
    Re: addresses of variables jt@toerring.de (Jens Thoms Toerring) - 2012-03-18 11:18 +0000
    Re: addresses of variables pete <pfiland@mindspring.com> - 2012-03-18 07:30 -0500
      Re: addresses of variables Zero <chefmuetze@web.de> - 2012-03-18 04:42 -0700
        Re: addresses of variables Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-19 10:52 -0400
          Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-19 12:55 -0500
            Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-19 14:30 -0400
              Re: addresses of variables jacob navia <jacob@spamsink.net> - 2012-03-19 20:11 +0100
                Re: addresses of variables hoganlong@gmail.com - 2012-03-19 12:17 -0700
                  Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-19 16:15 -0400
                    Re: addresses of variables hoganlong@gmail.com - 2012-03-19 14:18 -0700
                  Re: addresses of variables "io_x" <a@b.c.invalid> - 2012-03-19 23:26 +0100
              Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-20 03:52 -0500
                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-20 06:00 -0400
                  Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-20 16:47 -0500
                    Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-20 18:37 -0400
                      Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-21 17:58 -0500
                        Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-21 20:24 -0400
                          Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-21 23:53 -0500
                            Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-22 06:22 -0400
                              Re: addresses of variables Kenneth Brody <kenbrody@spamcop.net> - 2012-03-22 12:01 -0400
                                Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-24 16:09 -0500
                              Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-23 13:41 +0100
                                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-23 09:06 -0400
                                  Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-23 19:47 +0100
                                    Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-23 16:04 -0400
                                      Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 00:19 +0100
                                        Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-23 22:20 -0400
                                          Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 09:39 +0100
              Re: addresses of variables Anders Wegge Keller <wegge@wegge.dk> - 2012-03-20 20:02 +0100
                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-20 15:18 -0400
                  Re: addresses of variables Anders Wegge Keller <wegge@wegge.dk> - 2012-03-21 21:37 +0100
            Re: addresses of variables Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-20 11:52 -0400
              Re: addresses of variables Kenneth Brody <kenbrody@spamcop.net> - 2012-03-21 11:04 -0400

Page 1 of 2  [1] 2  Next page →

#18846 — addresses of variables

hello 

does the ansi standard define 
at what addresses variables will be found or is this dependent on each compiler,
I wonder, e.g. 
when I have this code
main()
{
int a, b, c, d;
char e;
}

whether those local variables are placed one after the other in memory (e.g. 0x100, 0x104, 0x108, 0x10C and 0x10D or
whether the can be aligned at different addresses 0x200, 0x100, 0x300...

Does the standard define those things...

Zero

[toc] | [next] | [standalone]

#18847

"Zero" <chefmuetze@web.de> wrote in message 
news:9524023.127.1332068169176.JavaMail.geo-discussion-forums@ynbq18...

> does the ansi standard define
> at what addresses variables will be found or is this dependent on each 
> compiler,
> I wonder, e.g.
> when I have this code
> main()
> {
> int a, b, c, d;
> char e;
> }
>
> whether those local variables are placed one after the other in memory 
> (e.g. 0x100, 0x104, 0x108, 0x10C and 0x10D or
> whether the can be aligned at different addresses 0x200, 0x100, 0x300...
>
> Does the standard define those things...

No.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#18848

Zero <chefmuetze@web.de> wrote:
> does the ansi standard define 
> at what addresses variables will be found or is this dependent on each compiler,
> I wonder, e.g. 
> when I have this code
> main()
> {
> int a, b, c, d;
> char e;
> }

> whether those local variables are placed one after the other in memory (e.g. 0x100, 0x104, 0x108, 0x10C and 0x10D or
> whether the can be aligned at different addresses 0x200, 0x100, 0x300...

> Does the standard define those things...

No, that's all up for the compiler to decide on its own. And the
variables don't even need to have addresses: unless you take the
address of a variable somewhere the compiler can very well "op-
timize out" a variable by keeping its value in a CPU register
or, if it finds it's not really needed, throw it out completely.

                              Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#18849

Zero wrote:
> 
> hello
> 
> does the ansi standard define
> at what addresses variables will be found or is this dependent on each compiler,
> I wonder, e.g.
> when I have this code
> main()
> {
> int a, b, c, d;
> char e;
> }
> 
> whether those local variables are placed one after the other in memory (e.g. 0x100, 0x104, 0x108, 0x10C and 0x10D or
> whether the can be aligned at different addresses 0x200, 0x100, 0x300...
> 
> Does the standard define those things...

No.

The most likely variations that 
I would expect to see for the above code,
is that the int addresses could be in either order 
and the char address may or may not be aligned on an int boundary
and may be either before or after the ints.

#include <stdio.h>

int
main(void)
{
    int a, b, c, d;
    char e;

    printf("0x%lx\n0x%lx\n0x%lx\n0x%lx\n0x%lx\n",
        (long unsigned)&a,
        (long unsigned)&b,
        (long unsigned)&c,
        (long unsigned)&d,
        (long unsigned)&e);
    return 0;
}


-- 
pete

[toc] | [prev] | [next] | [standalone]

#18850

Thank you!

[toc] | [prev] | [next] | [standalone]

#18860

Zero <chefmuetze@web.de> writes:

> Thank you!

Note, however, that by printing the addresses, that code may have
changed how the compiler would otherwise have stored the variables.

This isn't just compiler-dependent; it tends to be very sensitive to
optimization, as well.
-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

[toc] | [prev] | [next] | [standalone]

#18871

On 19-Mar-12 09:52, Lowell Gilbert wrote:
> Zero <chefmuetze@web.de> writes:
>> Thank you!
> 
> Note, however, that by printing the addresses, that code may have
> changed how the compiler would otherwise have stored the variables.

The Uncertainty Principle applied to C?  Good job!

> This isn't just compiler-dependent; it tends to be very sensitive to
> optimization, as well.

Indeed; this is a very basic optimization.  Any decent compiler will try
to eliminate variables, where possible, and to store the ones it can't
in registers.  Taking the address of a variable, though, forces that
variable to be stored in memory.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#18872

On 03/19/2012 01:55 PM, Stephen Sprunk wrote:
> On 19-Mar-12 09:52, Lowell Gilbert wrote:
>> Zero <chefmuetze@web.de> writes:
>>> Thank you!
>>
>> Note, however, that by printing the addresses, that code may have
>> changed how the compiler would otherwise have stored the variables.
> 
> The Uncertainty Principle applied to C?  Good job!
> 
>> This isn't just compiler-dependent; it tends to be very sensitive to
>> optimization, as well.
> 
> Indeed; this is a very basic optimization.  Any decent compiler will try
> to eliminate variables, where possible, and to store the ones it can't
> in registers.  Taking the address of a variable, though, forces that
> variable to be stored in memory.

Sort-of. Because of the as-if principle, &variable doesn't have to
actually identify the location (if any) where the variable is stored
unless some other part of the program would make the failure of the
program to store it there detectable.

For instance, if two non-overlapping objects have overlapping lifetimes,
and the program prints out the values of pointers to those two objects,
the print outs must identify different memory locations. If those
addresses are compared for equality, they must compare unequal. If such
a pointer is dereferenced, the behavior must be the same as if it
actually pointed at the object it's supposed to refer to. However, if
none of those things occur, printf("%p\n", (void*)&object) can print
just about any arbitrary memory location that is not, detectably,
currently in use for some other purpose, regardless of how (or whether)
the variable is actually stored.

[toc] | [prev] | [next] | [standalone]

#18874

Le 19/03/12 19:30, James Kuyper a écrit :
> On 03/19/2012 01:55 PM, Stephen Sprunk wrote:
>> On 19-Mar-12 09:52, Lowell Gilbert wrote:
>>> Zero<chefmuetze@web.de>  writes:
>>>> Thank you!
>>>
>>> Note, however, that by printing the addresses, that code may have
>>> changed how the compiler would otherwise have stored the variables.
>>
>> The Uncertainty Principle applied to C?  Good job!
>>
>>> This isn't just compiler-dependent; it tends to be very sensitive to
>>> optimization, as well.
>>
>> Indeed; this is a very basic optimization.  Any decent compiler will try
>> to eliminate variables, where possible, and to store the ones it can't
>> in registers.  Taking the address of a variable, though, forces that
>> variable to be stored in memory.
>
> Sort-of. Because of the as-if principle,&variable doesn't have to
> actually identify the location (if any) where the variable is stored
> unless some other part of the program would make the failure of the
> program to store it there detectable.
>
> For instance, if two non-overlapping objects have overlapping lifetimes,
> and the program prints out the values of pointers to those two objects,
> the print outs must identify different memory locations. If those
> addresses are compared for equality, they must compare unequal. If such
> a pointer is dereferenced, the behavior must be the same as if it
> actually pointed at the object it's supposed to refer to. However, if
> none of those things occur, printf("%p\n", (void*)&object) can print
> just about any arbitrary memory location that is not, detectably,
> currently in use for some other purpose, regardless of how (or whether)
> the variable is actually stored.

I would rather avoid such compilers.

The problem is that the compiler writer has NO idea what is going on
and why the value of that variable is being printed.

For instance

void *p = list->next;
#ifdef DEBUG
printf("Next pointer is %p\n",p);
#endif
} // function end

True, p is never used anywhere and the "as if" reasoning
invoked by you is "right".

The programmer however, wants to identify the faulty pointer
and that address will help him figure out a bug!

It is extremely dangerous when compilers start doing whatever
they want instead of LIMITING themselves to COMPILE the code!

jacob

[toc] | [prev] | [next] | [standalone]

#18875

> It is extremely dangerous when compilers start doing whatever
> they want instead of LIMITING themselves to COMPILE the code!
> 
> jacob

Ah, clearly the words of someone who has never written a compiler.

[toc] | [prev] | [next] | [standalone]

#18876

On 03/19/2012 03:17 PM, hoganlong@gmail.com wrote:
> 
>> It is extremely dangerous when compilers start doing whatever
>> they want instead of LIMITING themselves to COMPILE the code!
>>
>> jacob
> 
> Ah, clearly the words of someone who has never written a compiler.

He has written a compiler, and I gather he's done a fairly good job of
it. He knows immensely more about implementing a compiler than I do; but
I know little bit more about what the standard permits than he does.
Whether or not he's aware of the fact, he himself has made extensive use
of the "doing whatever they want" option, when it applies (and sometimes
when it does not) to implement a number of extensions to C - some fully
conforming, others not so much.

The standard permits things no reasonable implementation would ever do,
and things a good implementation should never do. I'm not sure that this
falls in either of those categories, though. Subject to the constraints
I mentioned in my previous message, I'm not sure it matters much for any
practical purpose what address is printed out. "Practical purposes"
necessarily involve violating one of the restrictions I mentioned.

For instance, if you print the address out to a file, and then read it
back in, that's a different matter; the address you read back in must,
if the object's lifetime has not yet ended, be dereferenceable and, when
dereferenced, actually refer to the same object. The same applies with
addresses that are displayed to the user, and then typed back in by the
user. The fact that this is true interferes with what would otherwise be
natural ways of implementing garbage collection for a conforming
implementation of C.

[toc] | [prev] | [next] | [standalone]

#18879

[stuff clipped]

Ah well, maybe I miss understood -- Now, I'm thinking the statement was a joke.

In any case, I hope no one took my statement badly.

[toc] | [prev] | [next] | [standalone]

#18880

<hoganlong@gmail.com> ha scritto nel messaggio 
news:32343424.564.1332184637390.JavaMail.geo-discussion-forums@vbla14...
>
>> It is extremely dangerous when compilers start doing whatever
>> they want instead of LIMITING themselves to COMPILE the code!
>>
>> jacob
>
> Ah, clearly the words of someone who has never written a compiler.

i'm agree with jacob, the game is going on by the programmer
not the compiler...

[toc] | [prev] | [next] | [standalone]

#18895

On 19-Mar-12 13:30, James Kuyper wrote:
> On 03/19/2012 01:55 PM, Stephen Sprunk wrote:
>> Indeed; this is a very basic optimization.  Any decent compiler will try
>> to eliminate variables, where possible, and to store the ones it can't
>> in registers.  Taking the address of a variable, though, forces that
>> variable to be stored in memory.
> 
> Sort-of. Because of the as-if principle, &variable doesn't have to
> actually identify the location (if any) where the variable is stored
> unless some other part of the program would make the failure of the
> program to store it there detectable.
> 
> For instance, if two non-overlapping objects have overlapping lifetimes,
> and the program prints out the values of pointers to those two objects,
> the print outs must identify different memory locations. If those
> addresses are compared for equality, they must compare unequal. If such
> a pointer is dereferenced, the behavior must be the same as if it
> actually pointed at the object it's supposed to refer to. However, if
> none of those things occur, printf("%p\n", (void*)&object) can print
> just about any arbitrary memory location that is not, detectably,
> currently in use for some other purpose, regardless of how (or whether)
> the variable is actually stored.

All of the above sounds reasonable, but when/why would any reasonably
sane implementation (i.e. not the DS9k) take advantage of that dubious
flexibility rather than use the "obvious" approach of storing the
variable in memory?

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#18900

On 03/20/2012 04:52 AM, Stephen Sprunk wrote:
> On 19-Mar-12 13:30, James Kuyper wrote:
...
>> Sort-of. Because of the as-if principle, &variable doesn't have to
>> actually identify the location (if any) where the variable is stored
>> unless some other part of the program would make the failure of the
>> program to store it there detectable.
>>
>> For instance, if two non-overlapping objects have overlapping lifetimes,
>> and the program prints out the values of pointers to those two objects,
>> the print outs must identify different memory locations. If those
>> addresses are compared for equality, they must compare unequal. If such
>> a pointer is dereferenced, the behavior must be the same as if it
>> actually pointed at the object it's supposed to refer to. However, if
>> none of those things occur, printf("%p\n", (void*)&object) can print
>> just about any arbitrary memory location that is not, detectably,
>> currently in use for some other purpose, regardless of how (or whether)
>> the variable is actually stored.
> 
> All of the above sounds reasonable, but when/why would any reasonably
> sane implementation (i.e. not the DS9k) take advantage of that dubious
> flexibility rather than use the "obvious" approach of storing the
> variable in memory?

Storing the variable in memory takes memory space and time; why bother
storing it there if you don't have to? A plausible implementation might
reserve a piece of memory to store the value in, if it actually needs to
be stored, and then find that it never actually needs to store the value
there. &variable would return that address, but the object never actual
resides in that memory. This doesn't sound like DS9K optimization to me.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#18915

On 20-Mar-12 05:00, James Kuyper wrote:
> On 03/20/2012 04:52 AM, Stephen Sprunk wrote:
>> On 19-Mar-12 13:30, James Kuyper wrote:
> ...
>>> Sort-of. Because of the as-if principle, &variable doesn't have to
>>> actually identify the location (if any) where the variable is stored
>>> unless some other part of the program would make the failure of the
>>> program to store it there detectable.
>>>
>>> For instance, if two non-overlapping objects have overlapping lifetimes,
>>> and the program prints out the values of pointers to those two objects,
>>> the print outs must identify different memory locations. If those
>>> addresses are compared for equality, they must compare unequal. If such
>>> a pointer is dereferenced, the behavior must be the same as if it
>>> actually pointed at the object it's supposed to refer to. However, if
>>> none of those things occur, printf("%p\n", (void*)&object) can print
>>> just about any arbitrary memory location that is not, detectably,
>>> currently in use for some other purpose, regardless of how (or whether)
>>> the variable is actually stored.
>>
>> All of the above sounds reasonable, but when/why would any reasonably
>> sane implementation (i.e. not the DS9k) take advantage of that dubious
>> flexibility rather than use the "obvious" approach of storing the
>> variable in memory?
> 
> Storing the variable in memory takes memory space and time; why bother
> storing it there if you don't have to? A plausible implementation might
> reserve a piece of memory to store the value in, if it actually needs to
> be stored, and then find that it never actually needs to store the value
> there. &variable would return that address, but the object never actual
> resides in that memory. This doesn't sound like DS9K optimization to me.

Hmm.  My mental model of how a compiler works is slightly different: the
compiler initially locates all variables in memory and then (provided
various conditions are met) migrates some of them to registers or
eliminates them entirely.  Taking the address of the variable would,
logically, prohibit such migration or elimination.  Allocating addresses
for memory variables would be done (probably by the assembler) long
after that took place.  Allocating addresses for variables that were
migrated or eliminated seems illogical.

(Perhaps that model is too simplistic, and I welcome correction, but so
far it has served me well enough to understand most optimizations.)

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#18917

On 03/20/2012 05:47 PM, Stephen Sprunk wrote:
> On 20-Mar-12 05:00, James Kuyper wrote:
...
>> Storing the variable in memory takes memory space and time; why bother
>> storing it there if you don't have to? A plausible implementation might
>> reserve a piece of memory to store the value in, if it actually needs to
>> be stored, and then find that it never actually needs to store the value
>> there. &variable would return that address, but the object never actual
>> resides in that memory. This doesn't sound like DS9K optimization to me.
> 
> Hmm.  My mental model of how a compiler works is slightly different: the
> compiler initially locates all variables in memory and then (provided
> various conditions are met) migrates some of them to registers or
> eliminates them entirely.  Taking the address of the variable would,
> logically, prohibit such migration or elimination. ...

The key point is that it is not the taking of the address that causes
such prohibition - it is using the address, or allowing it to be passed
somewhere where the compiler can't be sure it won't be used, that
actually triggers the prohibition.

> ... Allocating addresses
> for memory variables would be done (probably by the assembler) long
> after that took place. ...

The actual numerical address might not be allocated until later, but the
idea that an address might be needed can be recorded at an earlier stage
in the process.

> ... Allocating addresses for variables that were
> migrated or eliminated seems illogical. ...

So is code that takes an address without actually using it. But it's
precisely such code that I'm discussing. I'm mainly concerned with
whether or not such optimization is permitted, I'm less concerned with
whether or not there's a plausible way in which a reasonably-designed
implementation would produce such an optimization. But the key point is
that taking the address is not the right trigger - it's what happens to
that address that matters. If nothing "meaningful" happens to it, the
address doesn't have to mean anything real, and actual storage of the
value at the addressed location doesn't have to happen.

[toc] | [prev] | [next] | [standalone]

#18935

On 20-Mar-12 17:37, James Kuyper wrote:
> On 03/20/2012 05:47 PM, Stephen Sprunk wrote:
>> Hmm.  My mental model of how a compiler works is slightly different: the
>> compiler initially locates all variables in memory and then (provided
>> various conditions are met) migrates some of them to registers or
>> eliminates them entirely.  Taking the address of the variable would,
>> logically, prohibit such migration or elimination. ...
> 
> The key point is that it is not the taking of the address that causes
> such prohibition - it is using the address, or allowing it to be passed
> somewhere where the compiler can't be sure it won't be used, that
> actually triggers the prohibition.

Of course.

>> ... Allocating addresses for variables that were
>> migrated or eliminated seems illogical. ...
> 
> So is code that takes an address without actually using it. But it's
> precisely such code that I'm discussing. I'm mainly concerned with
> whether or not such optimization is permitted, I'm less concerned with
> whether or not there's a plausible way in which a reasonably-designed
> implementation would produce such an optimization. But the key point is
> that taking the address is not the right trigger - it's what happens to
> that address that matters. If nothing "meaningful" happens to it, the
> address doesn't have to mean anything real, and actual storage of the
> value at the addressed location doesn't have to happen.

If nothing "meaningful" was done with the address, then presumably other
optimizations would eliminate the code that generated it, thus allowing
the compiler to migrate or eliminate the variable.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#18937

On 03/21/2012 06:58 PM, Stephen Sprunk wrote:
> On 20-Mar-12 17:37, James Kuyper wrote:
...
>> implementation would produce such an optimization. But the key point is
>> that taking the address is not the right trigger - it's what happens to
>> that address that matters. If nothing "meaningful" happens to it, the
>> address doesn't have to mean anything real, and actual storage of the
>> value at the addressed location doesn't have to happen.
> 
> If nothing "meaningful" was done with the address, then presumably other
> optimizations would eliminate the code that generated it, thus allowing
> the compiler to migrate or eliminate the variable.

I don't follow that - why would a situation that renders it unnecessary
to store a variable in addressable memory imply that it's unnecessary to
store it anywhere?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#18938

On 21-Mar-12 19:24, James Kuyper wrote:
> On 03/21/2012 06:58 PM, Stephen Sprunk wrote:
>> On 20-Mar-12 17:37, James Kuyper wrote:
> ...
>>> implementation would produce such an optimization. But the key point is
>>> that taking the address is not the right trigger - it's what happens to
>>> that address that matters. If nothing "meaningful" happens to it, the
>>> address doesn't have to mean anything real, and actual storage of the
>>> value at the addressed location doesn't have to happen.
>>
>> If nothing "meaningful" was done with the address, then presumably other
>> optimizations would eliminate the code that generated it, thus allowing
>> the compiler to migrate or eliminate the variable.
> 
> I don't follow that - why would a situation that renders it unnecessary
> to store a variable in addressable memory imply that it's unnecessary to
> store it anywhere?

Concrete example:

int quux(void)
{
  int foo = 42;
  int *bar = &foo;
  return foo;
}

1. Both foo and bar start out in memory.
2. foo can't be migrated to a register because of the &foo.
3. bar is eliminated via dead code elimination.
4. foo can now be migrated to a register.
5. No address is needed for either foo or bar.

OTOH, say you have this:

#include <stdio.h>
int quux(void)
{
  int foo = 42;
  int *bar = &foo;
  printf("%p\n", (void*)bar);
  return foo;
}

1. Both foo and bar start out in memory.
2. foo can't be migrated to a register because of the &foo.
3. bar is migrated to a register.
4. An address is needed for foo but not for bar.

Can you give a similar example for what you're describing--and your
mental model of what a compiler would do with it?

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web