gor@cs.strath.ac.uk (Gordon Russell) (02/11/91)
Hi out there,
I am hoping that someone on the network can answer a compiler implementation
problem for me. The problem stems from my PhD research into compiler
techniques. If we consider the following program extract...
variable1 : integer;
procedure MAIN is
variable1 : integer;
result : integer;
----------------------------------------------------
procedure GET_RESULT(variable2: in out integer) is
begin
variable1=2;
variable2=variable1 + variable2;
end GET_RESULT;
----------------------------------------------------
begin
variable1=10;
get_result(variable1);
end MAIN;
My question is.......what is variable1 equal to at the end of MAIN?
There appears to be a number of options....either
(1) 4
(2) 12
(3) Something wierd
(4) Compiler dependent.
Evidentally, it is reliant on whether GET_RESULT operates on variable2
directly or indirectly. I am hoping that the results are compiler
dependent. Does anyone have an ADA compiler who is willing to test this?
I am especially interested to hear from official sources (if they are
reading this), since I do not want to break any validation suite
program.
Reply either to this newsgroup or by email. I will post a concensus if
comments are mailed directly to me. Please no flames if this program is
not syntatically correct, as it is the mechanism which I am inquiring
after. And yes, I do think that this is poor programming practice,
but when has that stopped anyone!
Thanx in advance.....Gordon Russell
gor@cs.strath.ac.uk
[I would expect that a look at the standard would answer this question
quickly. The issue of call by reference vs. call by copy in/copy out is at
least 30 years old. Algol 60 inadvertently introduced call by name which
forced situations like this to compute the answer 4. The various Fortran
standards have remained resolutely ambiguous, leaving the interpretation up
to the compiler writer. The "in out" syntax suggests that copy in/copy out
is expected, but what the syntax suggests and what the standard says are of
course entirely different things. -John]
--
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.mfeldman@eesun.gwu.edu (Michael Feldman) (02/13/91)
In article <5572@baird.cs.strath.ac.uk> Gordon Russell <gor@cs.strath.ac.uk> writes: > >procedure MAIN is > variable1 : integer; > result : integer; >---------------------------------------------------- > procedure GET_RESULT(variable2: in out integer) is > begin > variable1=2; > variable2=variable1 + variable2; > end GET_RESULT; >---------------------------------------------------- > begin > variable1=10; > get_result(variable1); > end MAIN; Please don't take this as a flame, Gordon; I'm posting it for others' use as well. The critique is not of the syntax errors, nor of the fact that this classical aliasing problem is poor style (which you point out), but the fact that the answer to this question is readily available in the LRM, namely sect. 6.2, in which it states quite clearly that this parameter is passed by copy-in/copy-out. This means that GET_RESULT is working on a local copy of variable1 (in its alias as variable2). For a _scalar_ parameter, the parameter semantics is well-defined. For a parameter of a _composite_ type, it's not: the implementation can choose copy-in/copy-out _or_ reference passing. This would have made your question more interesting. Here's an exercise I give to my classes, when we discuss this stuff: for some compiler you have access to, prove that the scalar passing is by value/result (aka copy-in/copy-out), and write programs to demonstrate the behavior of passing for composite types. Hint: most compilers use reference passing for large arrays (common sense, no?); some use value/result for small arrays. If the latter, find the "crossover". [This exercise is to create a _purposely_ erroneous program: we _want_ its behavior to depend on the mechanism :-)] <WARNING: SERMON COMING> The LRM is really a good source of information. Serious Ada folks should have it and use it. <HERE ENDETH THE SERMON> Mike Feldman -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
jb@rti.rti.org (Jeff Bartlett) (02/14/91)
In article <5572@baird.cs.strath.ac.uk>, gor@cs.strath.ac.uk (Gordon Russell) writes: > [ does Ada pass arguments by reference or copy in/copy out?] See ANSI/MIL-STD-1815A section 6.2 paragraph 7: .... The language does not define which of these two mechanisms is to be adopted for parameter passing, nor whether different calls to the same subprogram are to use the same mechanism. The execution of a program is erroneous if its effect depends on which mechanism is selected by the implementation. And section 1.6 paragraph 6: (c) Erroneous execution. The language rules specify certain rules to be obeyed by Ada programs, although there is no requirement on Ada compilers to provide either a compilation-time or run-time detection of the violation of such rules. .... The effect of erroneous execution is unpredictable. Jeff Bartlett Center for Digital Systems Research Research Triangle Institute jb@rti.rti.org mcnc!rti!jb (919)-541-6945 -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
mfeldman@seas.gwu.edu (Michael Feldman) (02/15/91)
In article <1991Feb13.211643.25777@rti.rti.org> jb@rti.rti.org (Jeff Bartlett) writes: >In article <5572@baird.cs.strath.ac.uk>, gor@cs.strath.ac.uk (Gordon Russell) writes: > >See ANSI/MIL-STD-1815A section 6.2 paragraph 7: > > .... The language does not define which of these two mechanisms is to > be adopted for parameter passing, nor whether different calls to the > same subprogram are to use the same mechanism. The execution of a > program is erroneous if its effect depends on which mechanism is > selected by the implementation. > C'mon, guys - a little precision please. This applies only to _structured_ parameters. The preceding paragraph (6) states clearly that _scalars_ are copied. I've bumped into a lot of Pascal folks learning Ada who think that passing an array as IN OUT will magically get it passed by reference. This is a trick used in Pascal - you pass an array as VAR even if it is being used as an input parameter, because the _Pascal_ standard requires that it be copied otherwise. This sticks you in a bind in Pascal, because you've turned an input parameter into something your procedure may inadvertently modify. So you've traded speed for reliability. Too bad, but this is what Prof. Wirth wanted. (It's carried over to Modula-2 also). Carrying the Pascal trick over to Ada is futile and unnecessary. An IN parameter _cannot_ be modified; the compiler won't allow it. This permits the implementer to pass an array (yes, even as an IN parameter) by reference to save copying time and space. As I said in a previous posting, most implementers will pass by reference any structure large enough to be of concern. But if you think that using the Pascal trick - artificially making the array IN OUT to _guarantee_ that it'll be passed by reference - will work, guess again. Mike Feldman
jls@yoda.Rational.COM (Jim Showalter) (02/16/91)
There is an unsafe aspect of passing access types as IN parameters in Ada
that is, sad to say, handled rather better in C++.
In Ada, you can pass an access type to a function as an IN:
type Some_Foo...
type Pointer is access Some_Foo;
function Some_Bar (Some_Param : in Pointer)...
And then, inside the function, dereference the pointer and modify the
pointed-to construct.
In C++, you can declare not only the pointer constant but the pointed
to construct constant as well. This allows passing by reference in a
read-only manner, which is NOT possible in Ada at present.stt@inmet.inmet.com (02/18/91)
Re: passing structured parameters by reference Michael Feldman writes: > PS: It seems to me that Ada9x could clarify the issue by simply requiring > that structured parameters be passed by reference (instead of the Ada83 > rule that it's implementation-dependent). Since a program whose behavior > depends upon the method of passing is - by definition of the LRM - > erroneous, the only programs that would break would be erroneous ones, > which Ada9x says it doesn't care about. So the clarification would be > upward compatible. Ada9x-ers: what would be the objections? Here are some important reasons for allowing by-copy parameter passing: 1) It supports parameter passing between parts of a distributed program which don't share memory. 2) It allows a slice of a packed array to be copied into an aligned temporary, rather than forcing every subprogram to handle a descriptor for an unaligned parameter. 3) It allows very short arrays/records to be passed in registers (e.g. a packed array of 16 booleans). 4) It is necessary when the actual parameter is in the form of a type conversion, and the target and source type don't have the same representation (e.g. one is packed and the other isn't). S. Tucker Taft Intermetrics, Inc. Cambridge, MA 02138
mfeldman@seas.gwu.edu (Michael Feldman) (02/22/91)
In article <20600085@inmet# stt@inmet.inmet.com writes:
#
# Here are some important reasons for allowing by-copy parameter passing:
#
# 1) It supports parameter passing between parts of a distributed
# program which don't share memory.
#
# 2) It allows a slice of a packed array to be copied into an aligned
# temporary, rather than forcing every subprogram to handle a descriptor
# for an unaligned parameter.
#
# 3) It allows very short arrays/records to be passed in registers
# (e.g. a packed array of 16 booleans).
#
# 4) It is necessary when the actual parameter is in the form of a type
# conversion, and the target and source type don't have the same
# representation (e.g. one is packed and the other isn't).
#
# S. Tucker Taft
# Intermetrics, Inc.
# Cambridge, MA 02138
I think we've come to the end of this thread. I think I started this one,
and I've read a lot of interesting network traffic on it, including some
nice private notes. I think Tucker has encapsulated the issues very well,
and I just want to thank him publicly for another enlightening summary
of an interesting language issue. Thanks!