Re: Where are returned values stored?

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Robert I. Eachus wrote:
> 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.  

I would disagree, but this is unimportant ;-)

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

In a POSIX environment, this would be normally called a
"process" -- not a thread. But a quick perusal of
the word "thread" in technical dictionaries online,
seems to return an array of muddled definitions
for "thread".

Threads of course can be implemented with differing
levels of sharing, and one possibility is to not share the
stack address space.

Anyway, I tend to live in the POSIX world, and so for
me at least, more stacks means carving up more of the
precious 2GB address space on 32 bit platforms. Once
everyone moves to 64 bit processors, then this is less
of a problem.

> On compilers where tasks are lightweight (all 
> share a single address space) you can't be quite so free with addresses. 

This is precisely the scenario that I was concerned
about (worst case scenario).

>  But it usually suffices to materialize a minimum return stack if per 
> task if and when it is referenced, and leave it unallocated otherwise. 

Yes, of course.  You must still however, carve up the
address space for the stacks, whether the vm pages are
allocated or not.

 >...

otherwise, interesting comments.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg