Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!uplherc!wicat!meph!gsarff
From: gsarff@meph.UUCP (gary sarff)
Newsgroups: comp.lang.c
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <00008@meph.UUCP>
Date: 18 Jan 90 00:07:06 GMT
References: <649@chem.ucsd.EDU> <14191@lambda.UUCP> <21778@mimsy.umd.edu>
Organization: WICAT Systems Inc., Orem Utah
Lines: 37

In article <21778@mimsy.umd.edu>, chris@mimsy.umd.edu (Chris Torek) writes:
>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'.
>
Read the code again. z=2? *a=1?  No no no!.
>
>I refuse to read or respond to anything futher from jlg (at least for a few
>weeks); it is bad for my blood pressure.

It might be better for everyone if you don't respond if you can't at least get
your examples right when you tell someone else they are wrong in a posting.
It might help lower your blood pressure too.