From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,984d3d7860d7c8c X-Google-Attributes: gid103376,public Path: controlnews3.google.com!news1.google.com!news.glorb.com!cyclone1.gnilink.net!gnilink.net!wn14feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Where are returned values stored? References: <75s9b0pgo91ctvlm5op2rcql82t9ip4me2@4ax.com> <1dptc.49822$tb4.1731604@news20.bellglobal.com> <2hv1auFhi91aU1@uni-berlin.de> In-Reply-To: <2hv1auFhi91aU1@uni-berlin.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Mon, 31 May 2004 08:58:02 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1086008282 198.96.223.163 (Mon, 31 May 2004 08:58:02 EDT) NNTP-Posting-Date: Mon, 31 May 2004 08:58:02 EDT Organization: Bell Sympatico Xref: controlnews3.google.com comp.lang.ada:952 Date: 2004-05-31T08:58:02-04:00 List-Id: Nick Roberts wrote: > "Warren W. Gay VE3WWG" 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