Path: utzoo!attcan!uunet!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <21778@mimsy.umd.edu>
Date: 12 Jan 90 04:07:54 GMT
References: <649@chem.ucsd.EDU> <14191@lambda.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 43

In article <14191@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
-In a previous article I made the incorrect statement that the number
-of machines which can be well optimized in the presence of pointers
-is growing narrow.  The fact is that the set of such machines is zero
-(at least, to the best of my knowledge).  Consider the following code:
-
-  z=1;
-  *a=2;
-  *b=1;
-
-If you could tell that a and b were not aliased (to each other
-or to z), the the generated code would be to set a register to
-one, store z, store b, increment, and store a.

1) you *can* tell aliasing (automatically, in the compiler) in many cases
   (not all).

-However, if you
-can't detect aliasing the sequence must be in the order given.
-On all machines I know, this would require at least one more
-instruction - so even on a RISC machine with no pipelining or
-vectorization to worry about this code would be 20% slower because
-of the possibility of aliasing.

2) even when you cannot, this is false.  The generated code
   would be `store 2 in register z', `store register z in *b',
   `decreemnt register z', `store register z in *a'.

-If these were arrays and this
-sequence of code were in an inner loop, this slowdown could
-strongly effect the whole code's performance.

... and you would simply write

	#pragma nonintersecting a, b

or something similar.

I refuse to read or respond to anything futher from jlg (at least for a few
weeks); it is bad for my blood pressure.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris