From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c6acbb9f2027b8c9 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wn12feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail From: Dave Thompson Newsgroups: comp.lang.ada Subject: Re: volatile vs aliased Message-ID: <8aqqk1p87dvoosd01cuqq2n5c7ive7omqt@4ax.com> References: <1128525722.605730.281980@g43g2000cwa.googlegroups.com> <87mzlnomca.fsf@ludovic-brenta.org> <1421562.dbAHjS9XJS@linux1.krischik.com> <1128598604.142021.239190@g44g2000cwa.googlegroups.com> <21305827.4TOYkjRP7N@linux1.krischik.com> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Oct 2005 02:16:41 GMT NNTP-Posting-Host: 12.75.205.203 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1129515401 12.75.205.203 (Mon, 17 Oct 2005 02:16:41 GMT) NNTP-Posting-Date: Mon, 17 Oct 2005 02:16:41 GMT Organization: AT&T Worldnet Xref: g2news1.google.com comp.lang.ada:5734 Date: 2005-10-17T02:16:41+00:00 List-Id: On Fri, 07 Oct 2005 08:33:06 +0200, Martin Krischik wrote: > Rolf wrote: > > > Do we have a difference to C/C++ increment operator here? consider > > > > pragma Volatile (x); > > x := x + 1; -- (1) > > vs. > > x++; -- (2) > > > > In the Ada case (1) we are forced to have "read from memory", > > "increment" and "write to memory" instructions, whereas in C/C++ (2) > > you can get a single "increment memory" instruction (presuming the > > mentioned assembler instructions exist on a given processor) > Not officially. In the C standard the abstract semantics for ++x and x++ with the result unused are the same as x += 1, which in turn is the same as x = x + 1 except that the _location_ of x is guaranteed evaluated only once, which makes no difference for a simple variable. And in standard C++ the same for the builtin types and hence operators; on class or enum types, like most operators in C++, these are user-defined if they exist at all, and thus may do anything. Of course (memory or other) reads and writes in the abstract machine can be optimized on a real machine unless volatile, and even for volatile the C standard (but not C++) contains an escape hatch in '90 6.5.3 or '99 6.7.3p6 that "what constitutes an access to [a volatile object] is implementation-defined" which means in theory it may be almost anything as long as it is documented. > Well, all machine code I have seen so far only have a INC for registers. And > if you think for it for a sec.: It can't be another way, even if there is a > INC for memory the CPU still has to read the memory increment internally > write back. > For some memory busses/interfaces RMW or read-locked-update can be special operations distinguished by hardware. And in the days of core this was common, because it could be inserted in the 'middle' of the destructive-read/rewrite cycle required anyway: PDP-6/10, -11 and VAX could use memory for any general insn operand except jump target including destination of 2-op (ADDM rn,mem; ADD #1, mem) or only of 1-op (AddOneSkipnever mem; INC mem). Actually you can and usually do use this _mode_ for jump target, but that uses the address not the contents which aren't modified. PDP-5/8/?12 had a specific memory reference instruction, one of only six (five excluding jump), Increment (memory) and Skip if Zero. As I recall on the 8/e this stretched the normal memory cycle of something like 1.8usec to something like 2.4usec, significantly less than 2 x 1.8 or whatever. > The truth is that x++ is a cheat and has allways been. x++ only exists > because it needs less memory to implement then a peep hole optimiser and - > in the light of modern CPU with powerfull MMUs and triple cache - without > any effect anyway. > It's a convenience to write (and read) x in source only once especially if complicated; of course a preprocessor macro could do the same and with decent CSE no net effect, but macros are the _most_ unstructured and inelegant part of C so that's hardly better. And C++ to a somewhat lesser extent; C++ works to eliminate _some_ macros. And _postfix_ like x++ yields the value before the modification, which prefix and compound x += 1 do not, and is useful for idioms like: i = 0; while( i < N ) do_something ( zero_origin_array [i++] ); - David.Thompson1 at worldnet.att.net