Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Default values in #define Date: Fri, 02 Sep 2016 08:40:54 -0700 Organization: None to speak of Lines: 44 Message-ID: References: <87twebuwwn.fsf@gmail.com> <36a5bcc3-9e30-468c-a3e1-4b9c9788d395@googlegroups.com> <1Kgvz.279$6d.174@fx26.iad> <8277ffd2-121d-4f3a-9bb0-ad3068696415@googlegroups.com> <502669cd-f0fc-4b99-8c8a-0d806c8b5f20@googlegroups.com> <566c947b-91d6-43c1-86aa-772f6cf21e35@googlegroups.com> <8760qg5592.fsf@news.bourguet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="6709"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18yVACtSNutBuwNwvC+DFMK" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:VVfgrI9Gcd2c8PNqw/HFrJXxxyI= sha1:4yDzdP/F9QSg8ydFWXzYm0KmJDo= Xref: csiph.com comp.lang.c:93117 Tim Rentsch writes: > Keith Thompson writes: [...] >> Given that 6.7.3p7 refers to what happens when an access occurs, rather >> than what is or is not an access, I don't see any room for treating ++v >> as a single access. (The side effect of the two accesses, one read and >> one write, are implementation-defined.) > > I sort of agree with you, but there is a big "but". > > The "but" is this. Although two accesses (one for reading, one > for writing) are required, my understanding is that both accesses > may be accomplished by a single machine instruction (eg, some > sort of read-modify-write). This possibility (to emphasize, as I > understand things) is a consequence of the famous last sentence > of 6.7.3p7 (and conveniently quoted above). I believe it was > intended to provide enough latitude so that, eg, a VQ read access > could be "the first half" of a read-modify-write, and a VQ write > access could be "the second half" of a read-modify-write. So > even though two accesses are required, that doesn't necessarily > translate into two separate machine instructions. I agree. More generally, the standard says nothing about the machine instructions that are generated for any given C code. If a "hello world" program can be implemented by a single HELLOWORLD CPU instruction, that's fine. > Of course, even assuming the above interpretation is correct, an > implementation is required to document what the correspondence is > between VQAs in the abstract machine and particular actions in > the real machine. So we should be able to discover, by reading > said documentation, whether such a mapping can occur in a given > implementation. It's not clear how much detail the implementation's documentation has to go into. Certainly gcc's documentation doesn't go down to the machine level. (It would have to do so separately for each target it supports.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"