Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Re: Aggressive optimization vs HLL's
Message-ID: <6054@lanl.gov>
Date: 15 Nov 90 19:40:13 GMT
References: <8960024@hpfcso.HP.COM>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 41

From article <8960024@hpfcso.HP.COM>, by mjs@hpfcso.HP.COM (Marc Sabatella):
> [...]
> For those with short memories: if you compute "pointer = base + offset" in
> one procedure, and pass the pointer to another procedure, then there is only
> one addition in the two procedures.  [...]
> [...]
> Or you could pass the array element by reference, but this requires relaxing of
> type rules if you want to actually access other members of the array in the
> called procedure.  [...]

No, actually it doesn't.  Not if the language has a "whole array" syntax.
In such a language, you pass the _specific_ section of the array that
the next procedure needs.  This section is completely type checked.
So, here are the two procedures:

      Procedure sub1(whatever)
      integer :: x(50), offset, end
      ...
      offset = 10
      end = 20
      ...
      sub2(x(offset:end))               !this adds offset to base
      ...
      end sub1

      Procedure sub2(integer :: a(:))
      ...               !in here, the add of offset to base never occurs
      end sub2

> [...]              It seems to me this relaxation, if allowed by the language,
> would tend to weaken non-aliasing assumptions as well, or would at least place
> heavier burdens on the programmer to avoid aliasing.

But, not by as much as pointers do!  And, not at all, if the loader
propagates information about aliasing through the call chain.  In this
case, the programmer is only burdened by aliasing when an unexpected
case of it actually occurs - the loader will warn him and he can take
the appropriate steps.  The rest of the time, the programmer doesn't
even have to think about it.

J. Giles