Re: Where are returned values stored?

["Robert I. Eachus" <rieachus@comcast.net>]

Warren W. Gay VE3WWG wrote:

> 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.

Several Ada compilers used a two-stack strategy.  One was the normal 
call stack, and the other was mostly for function return values.  Since 
you only needed to create things on the second stack for functions with 
return values that were not passed in registers, the overhead only 
appeared when you did have such functions.  And the compilers were 
'smart' enough to do any necessary splicing of values correctly.

So a function fubar returning "foo(x) & bar(y)" where foo and bar were 
functions returning strings would pass the descriptors in registers or 
as part of the calling sequence on the first stack.  Only the characters 
in the strings would go on the second stack, and of course fubar would 
just do the descriptor arithmetic and not touch the second stack at all.

I think Softech's ALS had a variation, on the two stack approach, but I 
didn't think much of it.  They used ping-pong stacks.  There were two 
stacks but the stack frames for the caller and callee were always on 
different stacks.  That way the caller could inspect the whole stack 
frame of a function that had just returned if necessary--but all it did 
was look for the location of the return value and also for the 
descriptor information if necessary.  However, in the case of nested 
calls with variable sized arguments returned through, the return values 
  had to be copied back and forth.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush