Re: Aliased arguments

James Giles wrote:

(snip)

> Fortran's rules for argument association are carefully
> designed to allow compilers with the choice of either
> call-by-reference or call-by-value/result (the latter is
> sometimes called copy-in/copy-out because that's what
> happens).  A given modern compiler often does *both*
> with the same procedure, even though the implementation
> may ostensively be call-by-reference.

The OS/360 compilers did value/result for scalar variables,
the manual actually explained it that way.  The even allowed
arguments to keep their value when called from a different
ENTRY point.

> Suppose, in the above SUB, that A is very heavily used
> within the procedure and B is seldom used.  The compiler
> may decide to make a local copy of A and keep it in a
> register for the duration.  Variable A now behaves exactly
> as if it was passed as value/result.  On the other hand, if
> the compiler just uses B from memory all the time, it may
> behave throughout with call-by-reference semantics.  This
> is a permitted optimization strategy in the code.

Compilers often keep variables in registers, though hopefully
not such that user programs will notice.

PL/I has the ABNORMAL attribute, and C has the volatile
attribute to tell the compiler that a variable could change
at unusual times.  (PL/I multitasking it one cause.)  Though
as far as I know, most compilers ignore both attributes.

(snip regarding variables in registers and aliasing)

> (This ignores the original question, which is why I changed
> the subject line.  Given that the semantics of EQUIVALENCE
> would have to be limited in special ways to provide for
> what you request, and the fact that EQUIVALENCE is mostly
> considered undesirable by many on the committee, it's not
> really likely that new capabilities will be added in that way.
> Too much committee work for what many would consider
> as waste of time.)

I think the latter is a big part of the reason EQUIVALENCE
hasn't changed much in almost 50 years.   Some people would
rather see it go away, and so try to ignore it.

-- glen

In article <_OqdnXTirvGAJRjfRVn-og@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:


> PL/I has the ABNORMAL attribute, and C has the volatile
> attribute to tell the compiler that a variable could change
> at unusual times.

F2003 has the VOLATILE attribute for the same thing (and ASYNCHRONOUS,
which is related).

But those attributes aren't for things like illegal aliasing. The kind
of aliasing in question is still illegal. I suppose the odds might be
better of implementation being such that it happens to work, but that is
not what the features are designed for and there is no guarantee that
they would have that effect.

The f2003 VOLATILE is for things such as interactions with separate
processes. Think things like shared memory.

The ASYNCHRONOUS attribute is a special case for I/O-related stuff.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Richard E Maine wrote:

(snip)

> F2003 has the VOLATILE attribute for the same thing (and ASYNCHRONOUS,
> which is related).

> But those attributes aren't for things like illegal aliasing. The kind
> of aliasing in question is still illegal. I suppose the odds might be
> better of implementation being such that it happens to work, but that is
> not what the features are designed for and there is no guarantee that
> they would have that effect.

> The f2003 VOLATILE is for things such as interactions with separate
> processes. Think things like shared memory.

The example in the post I was replying were more like the multitasking
case that you mention.  I agree that aliasing would still be illegal,
but it would seem that a proper implementation of VOLATILE, where
all writes go to memory, and all reads come from memory, would avoid
aliasing problems.  The fact that (most C and PL/I) compilers don't
actually do anything with the attribute, and it might be that Fortran
compilers won't either, does seem to indicate that aliasing is still
a problem.

-- glen

glen herrmannsfeldt wrote:
...
> The example in the post I was replying were more like the
> multitasking case that you mention.  [...]

As the author of the example in question, I have to say that
I don't see the multistaking angle.  The original article
wanted to call a subroutine like:

CALL SUB(Y, Y)

And then use the dummy arguments as TRANSFERs of each
other.  I was pointing out that even independent of the TRANSFER
angle, the call would be illegal if either dummy argument was
defined withing the subroutine.  I then gave an example of a
valid implementation that motivated *why* such aliasing was
illegal.  There wasn't any multitasking in sight.


--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

James Giles wrote:

> glen herrmannsfeldt wrote:
 

> As the author of the example in question, I have to say that
> I don't see the multistaking angle.

Reading through it again, I agree it isn't very obvious.

I was trying to answer the cases, other than aliasing,
where keeping variables in registers could cause problems.
I had thought you were trying to generalize to more than
just the aliasing case, but maybe not.

The case that IBM used as an example for the S/360 compilers
is the associated variable for direct access files.

To make sequential reading of direct access files easier they
supply a variable indicating the next record after the one
last read/written.   This variable is local to the routine that
declared the direct access file, though it will change when
any routine accesses the file.

Otherwise multitasking an asynchronous I/O are two cases where
variables do change at unexpected times.

-- glen