Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #1828
| From | Alexander Terekhov <terekhov@web.de> |
|---|---|
| Newsgroups | comp.programming.threads |
| Subject | Re: forcing the compiler to reload from memory with c++0x |
| Date | 2011-02-02 16:33 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <4D49795A.6C47C280@web.de> (permalink) |
| References | (14 earlier) <90c4d6f1-c539-4fdc-9b20-2cc6bc92dbe4@z20g2000yqe.googlegroups.com> <4D493C5C.83CA38C@web.de> <e065a7dd-2251-4568-b914-e3e5dc7269aa@x1g2000yqb.googlegroups.com> <4D495FE0.ED8A251E@web.de> <ecac5840-7645-478c-86b8-1f195a372860@g10g2000vbv.googlegroups.com> |
Dmitriy Vyukov wrote:
>
> On 2 фев, 16:45, Alexander Terekhov <terek...@web.de> wrote:
> > Dmitriy Vyukov wrote:
> >
> > [...]
> >
> > > Alexander, you are inconsistent here.
> > > Why can't printf() output go to nowhere on its own in the first place?
> > > Abstract output is basically the same as abstract memory accesses on
> > > abstract machine, no? And what is that abstract "standard output"
> > > device or file? If we go down to that formal hair-splitting level,
> > > then I believe we won't conclude anything useful. For example, is
> > > there dynamic memory? Well, I'm not sure. Is zero bytes of dynamic
> > > memory still dynamic memory? I guess it's nothing.
> > > If you want, there is always an implementation. And it's possible to
> > > loosely define such group of implementations as "sane industrial
> > > implementations". And in that context volatile access indeed means the
> > > most natural memory access instruction in generated code (MOV, LD or
> > > whatever). And that is observable. And that is what Anthony meant, I
> > > think.
> >
> > Stop abstracting into absurdity. "MOV, LD or whatever" are not
> > externally observable in the case of
> >
> > int main() {
> > Â volatile int i;
> > Â // volatile write = has no observable effect
> > Â i = 1;
> > Â // volatile read = has no observable effect
> > Â int n = i;
> >
> > }
> >
> > because the above program is the same as
> >
> > int main() {
> >
> > }
> >
> > for any reasonable observer of the outcome.
>
> I can observe it in disassembler or by timing the program. A compiler
> can't do any assumptions on how I'm going to observe it.
Can you really point out a chapter and verse guaranteeing that int
main() {} is faster than int main() { volatile int i = 1; int n = i; }?
As I told: disassembler is irrelevant.
regards,
alexander.
Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar
Re: forcing the compiler to reload from memory with c++0x Alexander Terekhov <terekhov@web.de> - 2011-02-01 14:17 +0100
Re: forcing the compiler to reload from memory with c++0x Alexander Terekhov <terekhov@web.de> - 2011-02-02 14:45 +0100
Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-02-02 07:02 -0800
Re: forcing the compiler to reload from memory with c++0x Alexander Terekhov <terekhov@web.de> - 2011-02-02 16:33 +0100
Re: forcing the compiler to reload from memory with c++0x Alexander Terekhov <terekhov@web.de> - 2011-02-01 16:32 +0100
Re: forcing the compiler to reload from memory with c++0x Alexander Terekhov <terekhov@web.de> - 2011-02-02 12:13 +0100
Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-02-02 04:54 -0800
Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-02-01 21:02 -0800
Re: forcing the compiler to reload from memory with c++0x Joshua Maurice <joshuamaurice@gmail.com> - 2011-02-01 15:19 -0800
Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-01 13:51 +0000
csiph-web