Re: Call by reference vs. call by value

[bobduff@world.std.com (Robert A Duff)]

In article <wvyafwh4pq7.fsf@swlpts1.ssd.ray.com>,
Felaco  <bcf@swlpts1.ssd.ray.com> wrote:
>I disagree with changing the syntax.  I feel that the pragma is the
>least intrusive way of giving the programmer some control, but not
>forcing the programmer to care when they wouldn't otherwise.  Another
>even simpler idea is to dictate that the compiler issue a warning when
>a call is made to a subunit with the same actual parameter used as an
                     ^^^^^^^ subprogram, I assume you mean
>'in' and an 'out' (or 'in out').  How hard would this be?

Impossible, since in many cases you can't tell what a given name denotes
until run time (array indexing, pointer dereferencing).  You could give
overly pessimistic warnings, but that wouldn't be helpful, since you
would have to warn for "P(X.all, Y.all);" if X and Y are of the same
type, so you would get zillions of spurious warnings.

Also, it's not just passing the same actual twice -- the problem can
also occur if you pass overlapping things.  (E.g., pass X and X(I).)

Also, you need to worry about aliasing with globals, and the compiler
can't see which globals are referenced.  So it would have to warn about
"P(X.all);", where X is a pointer, in case P accesses Y.all, and X and Y
happen to point to the same thing.

Also, Ada doesn't say aliasing is always wrong -- it depends on what the
subprogram does, and in what order.

>That's a good question - just how does the compiler determine how to
>pass array parameters where rep specs or packing applies?  Does it use
>bit pointers, or does it just make a properly aligned copy and pass it
>along?

The latter.  Bit pointers are less efficient than addresses on almost
all machines.  And if you pass a packed component by bit pointer, you
have to pass *all* parameters that way (since the subprogram's code has
to expect a bit pointer).  A nasty distributed overhead.  Alternatively,
you could generate two versions of code for every subprogram, one of
which expects addresses, and the other expects bit pointers.  This isn't
really acceptable, since it would double your code size.  You could do
better if you do fancy stuff at link time, but most compilers don't.

So, compilers generate code that expects an address of a properly
aligned thing, and in the packed case, make a copy at the call site that
is properly aligned.  This is what you expect -- pragma Pack means, "I
want to shrink the size, and I'm willing to put up with slower access."

>...  If the LRM dictated that all arrays were passed by reference,
>then the compiler could decide to use bit pointers (if the
>architecture provided efficient means to do so) or it could just
>resort to making a copy and passing a reference to it.

This doesn't make sense to me.  If the RM dictated by-reference, but the
compiler used by-copy, then the compiler would simply be wrong.  Passing
a copy by reference is by-copy semantics.  It doesn't matter who makes
the copy (caller or callee) nor where it is allocated, nor how it is
passed -- a copy is a copy.

No, I think if you dictated by-ref, then you would have to introduce the
Pascal rule, which says you can't pass packed components by-ref.  This
would be ugly, since it makes pragma Pack affect the semantics, rather
than just giving an optimization hint.  (Actually, pragma Pack *does*
affect the semantics of shared variables in a tasking context.  I find
that ugly, too.)

Note that Ada 95 has *some* types that require pass-by-ref (limited
records, for example).  If you pack something containing such a type,
then the compiler simply doesn't pack that component tightly.

- Bob