Re: Where are returned values stored?
From: Warren W. Gay VE3WWG (ve3wwg_at_cogeco.ca)
Date: 05/31/04
- Next message: Björn Persson: "Re: Why I like Ada"
- Previous message: Marin David Condic: "Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics"
- In reply to: Nick Roberts: "Re: Where are returned values stored?"
- Next in thread: Martin Krischik: "Re: Where are returned values stored? (follow up to yesterday's question)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 31 May 2004 08:58:02 -0400
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
- Next message: Björn Persson: "Re: Why I like Ada"
- Previous message: Marin David Condic: "Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics"
- In reply to: Nick Roberts: "Re: Where are returned values stored?"
- Next in thread: Martin Krischik: "Re: Where are returned values stored? (follow up to yesterday's question)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
