Re: volatile vs aliased

[Dave Thompson <david.thompson1@worldnet.att.net>]

On Fri, 07 Oct 2005 08:33:06 +0200, Martin Krischik
<krischik@users.sourceforge.net> wrote:

> Rolf wrote:
> 
<snip>
> > 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