Re: Where are returned values stored?

["Nick Roberts" <nick.roberts@acm.org>]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:AWjvc.22009$Hn.791710@news20.bellglobal.com...

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

Indeed, and in some cases it is actually quite hard to say whether threads
really share memory or not.

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

You may perhaps be interested to note that my design for the AdaOS kernel
(called 'Bachar') for the IA-32 makes use of segments to help alleviate the
problem.

Because each stack is in its own segment, it can be 'moved' (within the
underlying linear address space) without affecting the addresses of items on
the stack. Because stacks can be moved, it is feasible to start every stack
small and simply grow it as demand requires, even if this requires it to
grow 'huge' (100s of MB) sometimes. I like the way this avoids the necessity
for allocating big or indefinite things on the heap. (And by keeping stacks
page aligned, I can use trickery to move them rapidly.) Using segments
brings problems, but I am learning that it brings some advantages too!

> Once everyone moves to 64 bit processors, then this
> is less of a problem.

Hehe. In fact, 64-bit technology brings the prospect of objects remaining
allocated in virtual memory for years, even decades, maybe even centuries.
It's weird to think that I could compile a DSO into a certain address in
Linux-64 today, and some program written in 200 years' time will refer to it
/at the same address/, when trains run from planet to planet and people run
on batteries.

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

There we are. Using segments on the IA-32 gives me 45 bits of address space,
rather than just 32.

-- 
Nick Roberts