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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11241 invoked from network); 24 Aug 2020 17:21:44 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 24 Aug 2020 17:21:44 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id EC7299CABA; Tue, 25 Aug 2020 03:21:43 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id B95719CAB3; Tue, 25 Aug 2020 03:21:23 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="juUEamRx"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 6C14B9CAB3; Tue, 25 Aug 2020 03:21:21 +1000 (AEST) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by minnie.tuhs.org (Postfix) with ESMTPS id D17E89CAB1 for ; Tue, 25 Aug 2020 03:21:20 +1000 (AEST) Received: by mail-qk1-f180.google.com with SMTP id p4so8126273qkf.0 for ; Mon, 24 Aug 2020 10:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2j6ghEy0z9CZkJqG6eHqc5VVv2rohpa6i90xqk6A1IM=; b=juUEamRxXILox2aiCiIHBgPUv7YcXGAJNDR9PCUJE1puppuyNaP0r2e8i0VeYbnH3A Gt5bqD9HmUqrUEtZRVxCSlgEGJJpQkVJKjGndXPi0nfwizjs5a7pmAljdXpscd26jr5Q dWMTTqQuFHer42k/J/0O6HtUQf24lXvY8sHCPQAlpDkXR5bfOfyjC2kONtm2H9r53W6Q OFS4dpQIubTm/1UEfsL+DjPQRyvm3rc2OIjOESybLV81ZqnhHMgZqongGdriKLBeZigy Bo977bIrTO5niinYmQw9oMH51bBoStwHNach7WG0p6gA59/bZykUX+1h8NFjcaJBZLvz gNPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2j6ghEy0z9CZkJqG6eHqc5VVv2rohpa6i90xqk6A1IM=; b=FHmIT0yXYPpObs99HTGfmXumJgNzEA21UlIk5eRsrksA2lCffnr49NUslr0CWPRwGZ fCwgNZL6rqTaAeRayRBnE2Ra+aqBQ4oIRljUFJVu4nOhbp8HOY5hAgJb9LYsT+4v4Ru3 XiXkV+f5+kF5m7J3+SVcWL4QP3UR0wJGKXyDRhrfb8L+ueGMdAC9nsA0+QUnCKv1bWEM NgAaGKtcnmOCBqtcGS7UYey4z2psyLasPUJu/+nl65UdLey86P2FDpBWvJrSb/KDTxtH EvJHYV4pnr9o8eJP6W3mtNzeqSY/CL/RB1JGscwI71X8myUyNF0CbCZZC9nKLnSvwZn0 RDkA== X-Gm-Message-State: AOAM533Vyik2C9PrOmQ1K4fU24yvYcSI8olJd+0DQ27oTjwY0fEN82GO hZClAobNC9uO3RvtMuWSJdmWSbiaEaoMNQkA2CgZANoRgjE= X-Google-Smtp-Source: ABdhPJwGPUAEfP3Nfkp9JYo5s3azbRTm2eJ2I3n6DojzOThqU9tNXo0BuihGpZD5r5Lf2FA5OSf3Y8nE4o8S69ji3xY= X-Received: by 2002:a37:bcc:: with SMTP id 195mr2593856qkl.346.1598289679800; Mon, 24 Aug 2020 10:21:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dan Cross Date: Mon, 24 Aug 2020 13:20:43 -0400 Message-ID: To: John Cowan Content-Type: multipart/alternative; boundary="0000000000009cdc2e05ada2d085" 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: , Cc: The TUHS Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000009cdc2e05ada2d085 Content-Type: text/plain; charset="UTF-8" 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. > > Dennis's compiler AFAIK was never extended to anything but the PDP-11, > both as host and target. > That's my impression, as well. - Dan C. --0000000000009cdc2e05ada2d085 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 24, 2020 at 1:08 PM John Cowa= n <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 a= ddress space; but I'd have to double check the details.

That's always true on the PDP-11 an= d 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 tha= t cannot be extended, one can put it anywhere one wants in the virtual addr= ess space. E.g., right after the program text segment or whatever (effectiv= ely using the text as a guard to detect stack overflow). I don't know w= hy one would want to do that, except that it makes freeing the virtual addr= ess space slightly simpler when the process exits, but the point is that th= e Unix choice isn't the only way. That said, stacks and data growing to= ward each gives the maximum amount of flexibility.

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

Dennis's compiler AFAIK was never extended to anything = but the PDP-11, both as host and target.

That's my impression, as well.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.
=C2=A0
--0000000000009cdc2e05ada2d085--