Re: Where are returned values stored?

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Nick Roberts wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:1dptc.49822$tb4.1731604@news20.bellglobal.com...
...
>>Conceptually, there is _no_ reason a compiler _must_ copy a
>>return value. Consider a function like:
>>
>>function Foo return String is
>>   I : Integer := 23;
>>   S : String(1..3) := "Bar";
>>   X : Natural := 0;
>>begin
>>   ...
>>   return S;
>>end;
>>
>>To return S, all the compiler needs to do is to extend the
>>caller's stack frame to claim all the storage up to and
>>including S (I and S assuming sequential assignment), at
>>the point when Foo returns (return effectively does
>>reclaim the storage used for X however).
>>
>>Then the calling code can reference S as if it were a
>>local variable.  The space used for I is
>>wasted at this point, but temporarily, who cares?
>>
>>Once the compiler knows that the caller's use of the returned
>>value S is no longer required, the stack frame can be shrunk
>>back to the original size that it had prior to calling Foo.
>>
>>Is this done? Is it done by GNAT? I have no idea, but I
>>suspect that this is done in some places, some of the time,
>>by some compilers. Perhaps, someone in this group
>>can confirm/debunk this idea.
> 
> I don't think any compiler does quite as you suggest, Warren, but many do
> something similar: they allocate two stacks to each task, usually called the
> 'primary' and 'secondary' stacks; the primary stack is used as the normal
> stack, and the secondary is used exclusively for returning indefinite
> function results.

I cannot say for sure about the "in practice" aspect, since
I've never troubled myself to find out. But a second stack
seems to me to be an expensive way to solve the problem. It
certainly wouldn't be my first choice, if I were implementing
a compiler.

However, I can see how that could solve the problem if the
calling contention(s) available on a given hardware platform
demanded it.

A 2nd stack would mean fragmenting your memory space even
more, requiring a extra level of planning. Determining
stack requirements is always tricky when you have
subprograms that recurse. Otherwise static analysis would
be sufficient.

> In the general case (return statements returning expressions), an anonymous
> intermediate variable is used instead of S, and it is this anonymous
> variable that is allocated on the secondary stack.

Yes of course, since the same principle is at work.

> The only problem is that you have two stacks per task. That can add up to a
> lot of stacks for some programs! One optimisation is to determine if a task
> will never call a function that needs a secondary stack, and eliminate the
> (allocation of) the secondary stack for such tasks; if my memory serves me,
> I think I've heard of an Ada compiler that does this optimisation.
> 
> I think all those compilers which don't use a secondary stack use the heap
> (or some storage pool) instead.

It would be nice to have a survey of the different compilers
and methods used. So far we've not successfully trolled the
compiler vendors in CLA into saying more on the topic ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg