From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,af42f89f2159f3b6
X-Google-Attributes: gid103376,public
From: ncohen@watson.ibm.com (Norman H. Cohen)
Subject: Re: A note on GNAT 3.05 performance
Date: 1996/06/24
Message-ID: <4qm6kg$1f7a@watnews1.watson.ibm.com>#1/1
X-Deja-AN: 161842580
distribution: world
references: <dewar.835245019@schonberg> <4qm21c$qig@mdnews.btv.ibm.com>
organization: IBM T.J. Watson Research Center
reply-to: ncohen@watson.ibm.com
newsgroups: comp.lang.ada
Date: 1996-06-24T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <4qm21c$qig@mdnews.btv.ibm.com>, pontius@btv.ibm.com
(Dale Pontius) writes: 

|> When I first began looking at Ada, I wondered if if was 'pass by value'
|> or 'pass by reference'. The answer was, apparently, 'neither and both'.
|> It seemed to me that Ada was attempting to 'idealize' a concept by
|> using copy-in/copy-out that it shouldn't be.

Ada distinguishes the semantic model from the implementation.  The
semantic model is that all parameters are passed by copy-in/copy-out, but
the Ada rules allow this effect to be implemented for composite
parameters using pass by reference.  A pass-by-reference implementation
achieves the effect of a copy-in/copy-out semantic model as long as there
is no aliasing and as long as result parameters are not examined after a
procedure call that propagates an exception.

|> Now maintaining copy-in and copy-out will apparently have a performance
|> penalty, yet changing that aspect to pass-by-reference will not be
|> consistant with regular 'in' parameter passing.

It will be consistent with regular 'in' parameter passing as long as
programmers adhere to the sensible guidelines noted above:  Be careful
about aliasing and regard a subprogram call that propagates an exception
as leaving its out and in out parameters in an undefined state.

The reason GNAT 3.05 used a pass-by-copy IMPLEMENTATION. rather than the
pass-by-reference implementation most Ada compilers use for composites
longer than a word or two, was to be consistent with the implementation
of parameter passing that gcc uses for C.

This is not a problem unique to Ada.  Consider the following C++
declarations: 

   class T { ... };
   void f1 (T x);
   void f2 (T& x);
   void f3 (T* x);

Clearly, in the gcc C++ compiler, f1 must use the C parameter-passing
convention for passing a struct by copy and f3 must use the C
parameter-passing convention for passing a pointer-to-struct by copy.
However, f2 has the SEMANTIC MODEL of passing a struct by reference,
which is almost certainly IMPLEMENTED in the same way as f3.

This is quite close to the Ada situation.  (And the declaration

   void f2 (const T& x);

is quite similar to an Ada in parameter passed by reference.) GNAT simply
has to document that its conventions for passing a record are the same as
those for passing a C++ struct or class by reference.  Even if it were
not for Ada, this would have to be a full-fledged part of the gcc
parameter-passing scheme, even though it does not arise in C.

|> Are Ada pragmas frozen in concrete the way the rest of the language
|> is? Is it feasible to make 'pass by copy' and 'pass by reference'
|> for record parameters adjustable on a pragma basis? Is it desirable?

That was (a small) part of the motivation for access parameters.  If RT
is a record type and you are concerned about the potential inefficiency
of passing RT parameters by copy, and you don't trust your compiler to do
the right thing, you can write

   procedure P (X: access RT);

instead of

   procedure P (X: in RT);

and replace calls such as P(Actual) with P(Actual'Access).  However, this
is not a problem in practice (except momentarily, in GNAT 3.05, but
that's being fixed with alacrity).  Programmers are not encouraged to
engage in this sort of efficiency micromanagement unless there is a known
performance problem that can be shown to be attributable to parameter
passing by copy.

--
Norman H. Cohen    ncohen@watson.ibm.com