Path: utzoo!attcan!uunet!decwrl!ucbvax!liverpool.ac.uk!KPURCELL
From: KPURCELL@liverpool.ac.uk (Kevin Purcell)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <9009181242.AA20632@encore.encore.com>
Date: 18 Sep 90 11:54:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 70

On 17 Sep 90 08:21:00 GMT eru!hagbard!sunic!mcsun!tuvie!vexpert.dbai.tuwien.ac.
(eru!hagbard!sunic!mcsun!tuvie!vexpert.dbai.tuwien.ac.%!mst@edu.mit.bl) said:

>From article <1990Sep14.160429.2732@abcfd20.larc.nasa.gov>, by
> jcburt@ipsun.larc.nasa.gov (John Burton):
[stuff about pointers and merits versus multiply and add indexing of arrays]
>
> ... he discovered to his amazement that the programming
>guidelines include the following rules:
>
>	- 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.

If the machines has access to a vetorising processor or can run stuff
through a pipeline processor very quickly it is sometimes better to avoid
doing it explicitly fast (compared to say a PDP-11) with pointer and just
say what you really want. The compiler is probably better at picking up
this form to vectorise or unroll.

For example,

on some machines,

for(i=0; i<5; i++)
   a[i] = 0.0;

might execute faster as an unrolled loop:

a[1] = 0.0;
a[2] = 0.0;
a[3] = 0.0;
a[4] = 0.0;
a[5] = 0.0;

or it may get dispatched to a say 5 cpus in a vectorised procesor.

Writing it as:

i = 5;
ap = &a;
while(i--)
  *a++ = 0;

may not be pulled out by the optimiser.

In this case I think most optomisers would find it, but I can imagine
some slightly more complex constructs that might fool them.

There is a simple review of what RISC compilers do in UnixWorld Aug 1990
that expands on these ideas.

>
>Markus Stumptner                                mst@vexpert.at
>Technical University of Vienna                  vexpert!mst@uunet.uu.net
>Paniglg. 16, A-1040 Vienna, Austria             ...mcsun!vexpert!mst

I fear we are in danger of drifting into alt.religion.comp or even
comp.lang.c territory and way from futures.

Kevin Purcell          | kpurcell@liverpool.ac.uk
Surface Science,       |
Liverpool University   | Programming the Macintosh is easy if you understand
Liverpool L69 3BX      | how the Mac works and hard if you don't. -- Dan Allen