Re: The quest for the optimal calling convention; a model for specifying multiple calling conventions (longish)

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de>
27 Jan 2003 23:29:42 -0500

          From comp.compilers

Related articles
The quest for the optimal calling convention; a model for specifying m jsykari@gamma.hut.fi (Antti Sykari) (2003-01-12)
Re: The quest for the optimal calling convention; a model for specif fjh@cs.mu.OZ.AU (2003-01-17)
Re: The quest for the optimal calling convention; a model for specifyi jsykari@kosh.hut.fi (Antti Sykari) (2003-01-25)
Re: The quest for the optimal calling convention; a model for specifyi strohm@airmail.net (John R. Strohm) (2003-01-26)
Re: The quest for the optimal calling convention; a model for specifyi mailbox@dmitry-kazakov.de (Dmitry A.Kazakov) (2003-01-27)
| List of all articles for this month |

From: Dmitry A.Kazakov <mailbox@dmitry-kazakov.de>
Newsgroups: comp.compilers
Date: 27 Jan 2003 23:29:42 -0500
Organization: Compilers Central
References: 03-01-065 03-01-070 03-01-126 03-01-164
Keywords: optimize
Posted-Date: 27 Jan 2003 23:29:42 EST

On 26 Jan 2003 16:33:35 -0500, "John R. Strohm" <strohm@airmail.net>
wrote:
>> I can't think of a better solution than to enforce a mindset that any
>> parameter might be passed by reference and the programmer must not
>> rely on any assumptions on the passing method. If reference semantics
>> are desired, a pointer should be used. This seems more reasonable
>> than always enforcing a pass-by-value policy.
>>
>> [Gee, we're reinventing Fortran. -John]
>
>The fundamental problem is that everything is thinking in terms of
>"value semantics" or "reference semantics", rather than "in" "out" or
>"in out", to steal the Ada terminology. I suspect that this probably
>has something to do with lack of exposure to any language other than
>C.
>
>Ada's approach is that parameters are either input parameters, output
>parameters, or update parameters. An input parameter cannot be
>altered by the subprogram. An output parameter cannot be READ by the
>subprogram, only written. An update parameter can be both read and
>written.


[A correction] In fact an out parameter can be read in Ada 95. The
difference between out and in out is rather that an out parameter is
uninitialized (but constructed). One could say that there is also a
fourth "mode" used for the result of a function, which is not
cunstructed and thus can be unconstrained.


>Observe that, when the language is defined this way, the programmer no
>longer CARES about "value semantics" vs. "reference semantics". The
>programmer CANNOT screw himself by e.g. writing into a data structure
>that is intended to be constant but which, for efficiency and storage
>reasons, must be passed by reference. Nor can he screw himself by
>writing randomly into the ether when he treats something as reference
>that was passed by value. Further, the compiler is pretty much free
>to choose call-by-value or call-by-reference on a case-by-case basis.


This is absolutely true. There are also types which cannot be
arbitrarily passed either by-copy or by-reference. For instance, a bit
of a packed structure cannot be passed by-reference. A memory-mapped
hardware register cannot be passed by-copy. So Ada's approach is to
leave all dirty implementation details to the compiler, which is free
to use the most effective way of parameter passing.


---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.