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!cyclone.bc.net!news.uunet.ca!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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <2lNtc.56154$tb4.2140194@news20.bellglobal.com> Date: Fri, 28 May 2004 16:33:06 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1085776318 198.96.223.163 (Fri, 28 May 2004 16:31:58 EDT) NNTP-Posting-Date: Fri, 28 May 2004 16:31:58 EDT Organization: Bell Sympatico Xref: controlnews3.google.com comp.lang.ada:898 Date: 2004-05-28T16:33:06-04:00 List-Id: > Interesting to consider this with a recursive procedure, but yes, it > should work. > > JAF Recursive procedures offer no real challenge, except that if you passed a return value from a deeply nested call, all the way back down, you could temporarily have considerable "stack wastage". But there is no reason that an address comparison couldn't be made and a copy forced when a certain threshold of waste was reached. OTOH, if the compiler knows the usage is very short lived, it might as well just use it where it sits and "release" it after (especially if no further function/procedure calls are made, that will need use of the stack). Calling Conventions: If this indeed happens (on a given platform), I would think that the calling convention used is +critical+. For example, if you forced an Ada routine to use the C calling convention, I would bet that on most platforms, that all return values must be _copied_ or placed on the heap (temporarily). At least this would be true for strings/arrays etc. where the size was not known in advance. This is because most platforms (I think), have C programs pop off their stack frame as part of the return "process" (I believe this to be true of Wintel and Linux on Intel for example). So the compiler might be forced to copy the return value to some other location, or make some other arrangement for non Ada calling conventions. You obviously can't just re-extend the stack frame after a return because of the possibility of UNIX process signal calls or interrupt processing that may overwrite the stack area of interest. For this reason, I would expect that an Ada calling convention (when it supports this "return value in place" concept) probably has the called function Foo, performing the shrink of its stack frame as part of the return "processing"; but only enough to keep the return value protected. The caller then must finish the job by some prior arrangement known to the compiler, after the return value is no longer required. Just keep in mind that my responses on this thread are all conceptual/conjecture, and has no documented factual basis in any existing implementation ;-) Warren. James Alan Farrell wrote: > On Thu, 27 May 2004 13:05:06 -0400, "Warren W. Gay VE3WWG" > wrote: >>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. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg