From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12723 invoked from network); 25 Aug 2020 23:07:37 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 25 Aug 2020 23:07:37 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id C93179DF45; Wed, 26 Aug 2020 09:07:33 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 516D793D54; Wed, 26 Aug 2020 09:06:17 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=kilonet.net header.i=@kilonet.net header.b="kfdJ/lvr"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 7A3BA93D54; Wed, 26 Aug 2020 09:06:14 +1000 (AEST) Received: from p3plsmtpa08-02.prod.phx3.secureserver.net (p3plsmtpa08-02.prod.phx3.secureserver.net [173.201.193.103]) by minnie.tuhs.org (Postfix) with ESMTPS id ABBB193D49 for ; Wed, 26 Aug 2020 09:06:11 +1000 (AEST) Received: from medusa.kilonet.net ([108.30.24.253]) by :SMTPAUTH: with ESMTPA id Ai14kgNKms3kKAi14kayOJ; Tue, 25 Aug 2020 16:06:11 -0700 X-CMAE-Analysis: v=2.3 cv=N5FX6F1B c=1 sm=1 tr=0 a=DPaANz7MSPdDiKJlpBZCUg==:117 a=DPaANz7MSPdDiKJlpBZCUg==:17 a=y4yBn9ojGxQA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=2tsvuTQuAAAA:8 a=pGLkceISAAAA:8 a=QLaP3u-QfnM-V6RW9pUA:9 a=rEAGOPbGeWR9qBVb:21 a=fZpIlH5vj9rkqdGM:21 a=QEXdDO2ut3YA:10 a=3iLG7vNBRBJ2tKgoDyQA:9 a=X0D7L58schK7WoOV:21 a=BXzolgiDHeS3BNWT:21 a=m7yZCQEOHktHYsYz:21 a=_W_S_7VecoQA:10 a=w1QI8THEI4iyJQ0oNEIE:22 X-SECURESERVER-ACCT: krewat@kilonet.net Received: from [199.89.231.101] (ender.kilonet.net [199.89.231.101]) by medusa.kilonet.net (8.14.8/8.15.1) with ESMTP id 07PN69a1027091 for ; Tue, 25 Aug 2020 19:06:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kilonet.net; s=default; t=1598396770; bh=wt7RtS40f1z4C2Ou0dpno82xJ/EQ1IDXoLgJVk7TRV0=; h=Subject:To:References:From:Date:In-Reply-To; b=kfdJ/lvrh9Jlt73PAW2eQ9Cl01OdRrN7LjtwQ6JJE6cuIKMyvxQ0GtVhA9Q/Fj9/Z UmRyoVE2KaWpU2hwm0XZe9O13TSZdqMiAmV5wCgBto8IA/GNYiIqoOarVO+ym7Az46 88/S8aK6Zs3OMjnTxK3iIirh1+Lh5yLZa0Y1QdzE= To: tuhs@minnie.tuhs.org References: From: Arthur Krewat Message-ID: <950cbd43-9ddb-e723-943d-9fb7ce3f746e@kilonet.net> Date: Tue, 25 Aug 2020 19:06:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------464E95E9DF65F6130AC9B766" Content-Language: en-US X-CMAE-Envelope: MS4wfOEtaa9PEftYdFsxmgRKmkR0FYPbcLTMRqqLvro5jD1hwtFRs1j5cL+i7UurUhwRLjCpEy6sNIPQJbR1KOHxRND1mhorMb8KrDq1njpdqvW8b/P98uEp Vgq1NfuzRoXBUMwtwclG7fwuGSxcldWtluWBa2RODKoUqSYmvFHonhpH+qo1QPiQFZMCByRVjOm4WA== Subject: Re: [TUHS] Memory management in Dennis Ritchie's C Compiler X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multi-part message in MIME format. --------------464E95E9DF65F6130AC9B766 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/24/2020 1:20 PM, Dan Cross wrote: > On Mon, Aug 24, 2020 at 1:08 PM John Cowan > wrote: > > On Mon, Aug 24, 2020 at 12:00 PM Dan Cross > wrote: > > Stacks may be at the top of the user portion of the address > space; but I'd have to double check the details. > > > That's always true on the PDP-11 and Vax, no matter what the OS, > because the processor architecture (which has pre-increment and > post-decrement instructions, but not their counterparts) makes > anything but a downward-growing stack unmanageable. > > > Ah, but if one has a fixed-size stack that cannot be extended, one can > put it anywhere one wants in the virtual address space. E.g., right > after the program text segment or whatever (effectively using the text > as a guard to detect stack overflow). I don't know why one would want > to do that, except that it makes freeing the virtual address space > slightly simpler when the process exits, but the point is that the > Unix choice isn't the only way. That said, stacks and data growing > toward each gives the maximum amount of flexibility. > > In OSes without virtual memory like RSX-11[ABC], RT-11, and > mini-Unix/LSX-11, what counts as the top naturally varies. > > On TOPS-10, I got into the habit of putting the PDL at the end of the lowseg. If it ran over, it would die. ak --------------464E95E9DF65F6130AC9B766 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 8/24/2020 1:20 PM, Dan Cross wrote:
On Mon, Aug 24, 2020 at 1:08 PM John Cowan <cowan@ccil.org> wrote:
On Mon, Aug 24, 2020 at 12:00 PM Dan Cross <crossd@gmail.com> wrote:
Stacks may be at the top of the user portion of the address space; but I'd have to double check the details.

That's always true on the PDP-11 and Vax, no matter what the OS, because the processor architecture (which has pre-increment and post-decrement instructions, but not their counterparts) makes anything but a downward-growing stack unmanageable.

Ah, but if one has a fixed-size stack that cannot be extended, one can put it anywhere one wants in the virtual address space. E.g., right after the program text segment or whatever (effectively using the text as a guard to detect stack overflow). I don't know why one would want to do that, except that it makes freeing the virtual address space slightly simpler when the process exits, but the point is that the Unix choice isn't the only way. That said, stacks and data growing toward each gives the maximum amount of flexibility.

In OSes without virtual memory like RSX-11[ABC], RT-11, and mini-Unix/LSX-11, what counts as the top naturally varies.


On TOPS-10, I got into the habit of putting the PDL at the end of the lowseg. If it ran over, it would die.

ak




--------------464E95E9DF65F6130AC9B766--