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: controlnews3.google.com!news1.google.com!news.glorb.com!cyclone1.gnilink.net!gnilink.net!wn13feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Where are returned values stored? References: <75s9b0pgo91ctvlm5op2rcql82t9ip4me2@4ax.com> <1dptc.49822$tb4.1731604@news20.bellglobal.com> <2hv1auFhi91aU1@uni-berlin.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 02 Jun 2004 08:42:08 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1086180128 198.96.223.163 (Wed, 02 Jun 2004 08:42:08 EDT) NNTP-Posting-Date: Wed, 02 Jun 2004 08:42:08 EDT Organization: Bell Sympatico Xref: controlnews3.google.com comp.lang.ada:1025 Date: 2004-06-02T08:42:08-04:00 List-Id: 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