🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #1932

Re: A question on volatile accesses

#1932
From: Ron Guilmette
Date: Sat, 03 Nov 1990 21:29
65 lines
2394 bytes
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.
Technical Details
Message-ID: <2402@lupine.NCD.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watserv1!watmath!att!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!sgi!decwrl!infopiz!lupine!rfg
References: <2388@lupine.NCD.COM> <27407@mimsy.umd.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watserv1!watmath!att!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!sgi!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.std.c
Subject: Re: A question on volatile accesses
Message-ID: <2402@lupine.NCD.COM>
Date: 3 Nov 90 21:29:59 GMT
References: <2388@lupine.NCD.COM> <27407@mimsy.umd.edu>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 65