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: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Where are returned values stored? Date: Thu, 3 Jun 2004 03:00:21 +0100 Message-ID: <2i7felFkcejkU1@uni-berlin.de> References: <75s9b0pgo91ctvlm5op2rcql82t9ip4me2@4ax.com> <1dptc.49822$tb4.1731604@news20.bellglobal.com> <2hv1auFhi91aU1@uni-berlin.de> X-Trace: news.uni-berlin.de P9TfsUmSJMAkcmXK7oJzbA2vaDoYHJ1tZb/kQVGCQoU6iLj10= X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Xref: g2news1.google.com comp.lang.ada:1047 Date: 2004-06-03T03:00:21+01:00 List-Id: "Warren W. Gay VE3WWG" 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