Re: Where are returned values stored?

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

Warren W. Gay VE3WWG wrote:

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

You are thinking like an embedded programmer, and probably should be 
using SPARK.  In a virtual memory environment, things are much 
different. I've lived in both worlds. If you make tasks "heavy" threads, 
with their own virtual address space, the number of stacks and their 
size is a non-issue.  On compilers where tasks are lightweight (all 
share a single address space) you can't be quite so free with addresses. 
  But it usually suffices to materialize a minimum return stack if per 
task if and when it is referenced, and leave it unallocated otherwise. 
Of course, if a function returns a huge number of bytes, you allocate 
the space from the heap, and put a descriptor on the return stack.

The definitions of minimum return stack size and huge are of course 
compiler dependent.  And of course it is a bit of a pain if you have to 
grow the return stack by copying.  (The return stack can contain 
addresses, but references into locations in the return stack have to be 
offsets.  That way you can copy it if needed to expand it.)  But 
definitions like an 8 kByte startiing size and treating anything over 1 
kByte as 'huge' work pretty well.

This is a side-effect of the Ada culture.  Although Ada allows returning 
huge objects, for any meaning of huge, from functions and allocating 
huge object in stack frames, it turns out that in practice most huge 
arrays get allocated in package specs or bodies.  When we were creating 
the Ada/SIL compiler a lot of things were postponed until we actually 
ran into them.  We went for months without deciding what to do when any 
stack exceeded 128 kBytes.  Final decision?  Raise Storage_Error.  The 
few logged cases of running into this limit were all accidental 
indefinite recursion, or attempts to allocate a maximum size String 
(2**31-1 bytes) or other maximum size array.

Alsys has/had, whatever the name is now for the French compiler, a limit 
of 8 kBytes that was pretty similar.  If an object type had an 
indefinite size that could be greater than 8 k, it would go on the heap 
with a descriptor on the stack.  It allowed them to support indefinite 
record types (records with discriminants that have defaults and 
composite components whose bounds depend on one or more discriminants, 
where the object is declared without a discriminant constraint).  Alsys 
used the name mutant records, and it became associated with their method 
of managing such objects more than the object types themselves.  It 
really would be handy if such records had a short meaningful name...

-- 

                                           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