NEVERMIND! (was: Re: A question on volatile accesses)

[Ron Guilmette]

In article <1990Nov3.231856.20556 at zoo.toronto.edu> henry at zoo.toronto.edu (Henry Spencer) writes:
>
>>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.

OK.  Let me apologize to everyone for having wasted net bandwidth on
this question.

Here is what was *actually* happening.

	char *extern_charptr_func ();
	int extern_int_func ();

	void example ()
	{
		int i = extern_int_func ();
		volatile char *cp = extern_charptr_func ();

		do {
			i--;
			(++cp)[0];
		} while (i);
	}

Now in this particular compiler (which happens to be GCC, as I believe
Henry guessed) I asked the author (Richard Stallman) some time back to
add a nice little feature for me, which he was nice enough to do.

The feature that I asked for was to have the values of volatile
expressions evaluated, even if the result was not used, so that:

	volatile char *cp;

		...
		*cp;
		...

would in fact cause a (byte) fetch from the address pointed to by `cp'.

Now apparently, the ANSI standard doesn't explicitly require such treatment,
but it certainly doesn't rule it out either.  I found this feature quite
useful in certain circumstances (e.g. driving I/O chips) in order to be
able to code (entirely in C) a simple load operation (on say a device
register which recognizes the load itself as a signal to do something).

Unfortunately, due to a minor oversight while implementing this enviable
feature, Richard caused such expressions to have code for their side
effects generated *twice*.

Thus, for my complete example above, the pointer `cp' was being incremented
*twice* (once before the indirection and once after) for each trip thru
the loop.  The latter increment was (later) getting stuffed into a
delay slot.

Serves me right for asking for a bizzare feature.

Anyway, I just tracked down the bug and wrote a three line fix.  Now,
only one increment is generated (prior to the indirection) and correct
ordering of operations is maintained nicely.  (Try that on your binary-
only compilers!)

So anyway, NEVERMIND!