[comp.std.c] A question on volatile accesses

rfg@lupine.ncd.com (Ron Guilmette) (11/03/90)

Given the following code:

	volatile int *ip;

	void foobar ()
	{
		register int i;

		do
			i = *++ip;
		while (i);
	}

I'd like to know if the standard allows the incrementation of `ip'
to occur *after* the volatile access.

In other words, could the program above legally be treated as:

	volatile int *ip;

	void foobar ()
	{
		register int i;

		do {
			i = *ip;
			++ip;
		} while (i);
	}

This seems entirely counter-intutive to me, and yet one supposedly ANSI
C compiler provides such a treatment.

I guess the question comes down to this: When you dereference a
pre-incremented pointer, can you always safely assume that the
pre-increment has already occured by the time the indirection
through the pointer occurs?

Note that the variable `ip' is not itself volatile.

steve@taumet.com (Stephen Clamage) (11/04/90)

rfg@lupine.ncd.com (Ron Guilmette) writes:

|	volatile int *ip;
|	void foobar ()
|	{
|		register int i;
|		do
|			i = *++ip;
|		while (i);
|	}
|I'd like to know if the standard allows the incrementation of `ip'
|to occur *after* the volatile access.
|In other words, could the program above legally be treated as:
|		do {
|			i = *ip;
|			++ip;
|		} while (i);
|This seems entirely counter-intutive to me, and yet one supposedly ANSI
|C compiler provides such a treatment.

You have changed the semantics here.  Forgetting volatile for the moment,
	 i = *++ip;
is in some sense equivalent to
	 ++ip;
	 i = *ip;
or to
	i = ip[1];
	++ip;
by the definition of pre-increment.

|I guess the question comes down to this: When you dereference a
|pre-incremented pointer, can you always safely assume that the
|pre-increment has already occured by the time the indirection
|through the pointer occurs?

There is no sequence point within the expression
	 i = *++ip;
The side effect of incrementing ip must occur before executing the
statement following the ";", and the expression must be evaluated
AS IF it occurred before dereferencing ip.

So yes, the expression must behave as though the increment occurred
before the dereference, but no, the increment need not actually
occur then.  Since ip is not itself volatile, as you pointed out,
this distinction should not make any difference.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com

chris@mimsy.umd.edu (Chris Torek) (11/04/90)

In article <2388@lupine.NCD.COM> rfg@lupine.ncd.com (Ron Guilmette) writes:
>Given ... volatile int *ip; ... i = *++ip;
>I'd like to know if the standard allows the incrementation of `ip'
>to occur *after* the volatile access.

Yes.

>In other words, could the program above legally be treated as:
>... i = *ip; ++ip; ...

No.  The equivalent expansion is, instead,

	i = ip[1]; ++ip;
	/* or: tmp = ip + 1; i = *tmp; ip = tmp; */

Even if `ip' itself were volatile (`volatile int *volatile ip;') the
same sequence could be used, since `volatile' really does not say much
anyway.  The main idea behind `volatile' is to make sure that loads
and stores are not deferred beyond sequence points.  Without volatile,
the sequence

	i = *ip; ip++; i *= *ip;

could be computed as

	x = ip[1]; y = ip[0]; i = x * y; ip += 2;

whereas with it, the x and y above must be loaded in the other order.
I am not at all certain whether ip must be altered between those
operations (if ip itself were volatile, this would be true).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris

rfg@NCD.COM (Ron Guilmette) (11/04/90)

Chris Torek's response to my question was (at first) incredibly confusing
to me.  I see now that he (perhaps) missed the real thrust of my question,
and this was entirely my fault because I stated the question badly.

Let me restate it one more time, and I'll try to make it clear what I'm
asking about.  Consider the following code:

	int array[2] = { 1, 2 };

	int example ()
	{
		volatile int *ip = &array[0];
		int i;

		i = *++ip;

		return i;
	}

My question is this.  Does the ANSI standard permit the function shown
above to delay the pre-increment until *after* the pointer indirection
occurs (thus causing the function to return `1') or does the standard
*require* that the pre-increment occur *before* the pointer indirection
(thus in turn requiring the function to always return `2')?

My (naive?) assumption is that the standard requires that the pre-increment 
occur *before* the resulting value is used as a basis for indirection,
but I need to know where the standard states this requirement.

The reason I need to know is as follows.

I am working with a (supposedly) ANSI C compiler which generates code for
a target instruction set which includes delayed branch instructions.
When given code like:

	int array[2] = { 1, 2 };
	int j = 0;

	int example ()
	{
		volatile int *ip = &array[0];
		int i;

		do {
			i = *++ip;
		while (j);

		return i;
	}

The compiler generates code in which the pre-increment operation gets
stuffed into the delay slot of the (conditional) branch instruction
which is the translation of the `while' clause of the loop.

Thus, the pre-increment occurs *after* the indirection.

Thus, the function returns `1' and not `2'.

So is this a violation of the ANSI standard or what?

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

henry@zoo.toronto.edu (Henry Spencer) (11/04/90)

In article <2388@lupine.NCD.COM> rfg@lupine.ncd.com (Ron Guilmette) writes:
>	volatile int *ip;
>			i = *++ip;
>
>I'd like to know if the standard allows the incrementation of `ip'
>to occur *after* the volatile access.

It depends on what you are asking.  If I am not mistaken, it is proper for
the change to `ip' -- the variable -- to occur only after the access.
However, the access itself *must* use the incremented value, even if that
value has not yet been written back into the variable; the definition of
the prefix `++' operator demands this.

>In other words, could the program above legally be treated as:
>			i = *ip;
>			++ip;

No, although it could be treated as:

			i = *(ip + 1);
			++ip;

The volatility of the thing pointed at, by the way, has absolutely no
bearing on the issue (except insofar as a kludged-in implementation of
`volatile' may have introduced bugs).

>This seems entirely counter-intutive to me, and yet one supposedly ANSI
>C compiler provides such a treatment.

Your use of the word "supposedly" is appropriate.  The way you asked this
implies that this doesn't happen if the thing pointed at is not `volatile'.
My diagnosis would be as mentioned above:  somebody kludged `volatile' into
a compiler that originally didn't support it, and broke the prefix `++'
operator in the process.
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry

gwyn@smoke.brl.mil (Doug Gwyn) (11/04/90)

In article <2388@lupine.NCD.COM> rfg@lupine.ncd.com (Ron Guilmette) writes:
>	volatile int *ip;
>			i = *++ip;
>In other words, could the program above legally be treated as:
>	volatile int *ip;
>			i = *ip;
>			++ip;

"volatile" has nothing to do with this.

The above rewrite would be incorrect in any case.  Better would be
	volatile int *ip;
			i = ip[1];
			++ip;

The only places in the code where side effects are required to be
brought up to date (synchronized) are at sequence points, such as
at the end of the assignment statement in the original code.

gwyn@smoke.brl.mil (Doug Gwyn) (11/04/90)

In article <2402@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>So is this a violation of the ANSI standard or what?

It's simply a violation of C.  You don't need to look in the standard
to know that *++ip means "increment the pointer then fetch what is now
pointed at".  The value of "++ip" is the only issue here and that has
been well defined ever since Dennis invented it.

chris@mimsy.umd.edu (Chris Torek) (11/05/90)

In article <27407@mimsy.umd.edu> I wrote:
>	i = *ip; ip++; i *= *ip;
>could be computed as
>	x = ip[1]; y = ip[0]; i = x * y; ip += 2;

Oops, that should be `ip += 1' (or ip++ or ++ip).

In article <2402@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes
further:
>Thus, the pre-increment occurs *after* the indirection.
>Thus, the function returns `1' and not `2'.
>So is this a violation of the ANSI standard or what?

Yes, it is incorrect (and the presence or absence of `volatile' is
irrelevant to this answer).  `i = *++ip' must indirect through the
value that results from the increment, even though the increment itself
need not occur before the indirection.  (Consider a machine with
several functional units, which might handle `i = *++ip' as:

	tell unit 0: `read memory at 4(r9)'
	tell unit 1: `compute r9 + 4'
	wait for unit 0 to release r9 (indicating it has saved the old value)
	tell unit 1: `store result in r9'
	tell unit 0: `store result in r10'

in which the increment and the fetch happen `almost simultaneously'.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris