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.
gor@computer-science.strathclyde.ac.uk (02/13/91)
With regards to my recient posting concerning parameter passing
in ADA, I would like to thank the overwhelming responce to my article.
In almost every case, the answer would appear to be 12. This is confirmed
by the ADA LRM (6.3.6), in the 1983 version (yes, I do have a copy, but I
never found this reference until it was pointed out to me).
This will mae my supervisor very unhappy, since he was of the impression
that I would have to make use of passing by reference, when I was suggesting
parameter passing by value. Your letters go along way to justify this.
I would like to thank Bill Yow, Gene Ressler, Brian Hanafee, Mark Streich,
Thomas Mueller, Trevor Bourget, Cyrille Comer, and Mike Feldman.
Thanx again,
Gordon Russell
PhD student, University of Strathclyde.
--
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.