Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: addresses of variables |
| Date | 2012-03-20 18:37 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <4F6906AC.9000509@verizon.net> (permalink) |
| References | (4 earlier) <jk7ru4$om5$1@dont-email.me> <4F677B52.4020500@verizon.net> <jk9gfp$tdt$1@dont-email.me> <jk9kfh$g5v$1@dont-email.me> <jkatt4$6h7$1@dont-email.me> |
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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web