Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <63212@lanl.gov>
Date: 17 Sep 90 22:36:50 GMT
References: <3643@vexpert.dbai.tuwien.ac.at>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 54

From article <3643@vexpert.dbai.tuwien.ac.at>, by mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner):
> [...]
> 	- Do not use the increment and decrement operators (++ and --)
> 
> 	- Do not use pointer incrementing for sequential array access
> 
> This was a year ago, and my memory is fuzzy.  As far as I remember,
> according to the manual, in most cases using ordinary
> assignment/expression syntax and incrementing an array index will be
> MUCH FASTER since the compiler has more freedom in keeping values in
> registers instead of having to store them back in memory immediately.

This is quite possibly true.  You see, pointers are unrestricted alias
generators.  If you have a subroutine which (say) copies one array into
another:

    for (i=0;i<max;i++)
      A[i] = b[i];

The compiler probably just does the constant folding and zips through
the assignment.  If you do the following instead:

    for (lim=a+max; a<lim; *a++ = *b++);  /* the usual idiom */

The compiler probably has to complete each store of 'a' before the load
of the next 'b'.  Further, since *b may be an alias for itself or for
'a', the values of the pointers are probably stored and reloaded each
trip through the loop as well.

For example, suppose memory is like this:

    address     content         name
    0199        0200            a
     ...
    0200        0300            b _and_ *a
     ...
    0300        0123            *b

In this case, the arrays don't overlap, but *a points to the place that
'b' is stored - so the first trip through the loop alters the location
of the *b array.  This is legal in C, the compiler has no way of knowing
that the user didn't do this, the compiler must genetrate code to allow
this to happen - in this case: 'b' must be reloaded after each loop
trip.  Other memory configurations would require other special actions.
The only "safe" thing the compiler can do is store/reload _all_ the
variables on each loop trip.

Of course, this shows that the CDC compiler was wrong.  The two programs
given here should both generate the same code (since compiler technology
is sufficiently advanced for the compiler to see that both do the same
thing - except for setting 'i' and/or 'lim').  However, the compiler
should generate the same _slow_ code for both.

J. Giles