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=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27240 invoked from network); 2 Mar 2022 02:19:52 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Mar 2022 02:19:52 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2EC559D027; Wed, 2 Mar 2022 12:19:51 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 61C579CFD0; Wed, 2 Mar 2022 12:18:25 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=bsdimp-com.20210112.gappssmtp.com header.i=@bsdimp-com.20210112.gappssmtp.com header.b="sjom/chg"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 5B0659CFD0; Wed, 2 Mar 2022 12:15:57 +1000 (AEST) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by minnie.tuhs.org (Postfix) with ESMTPS id 494CE9CC02 for ; Wed, 2 Mar 2022 12:15:56 +1000 (AEST) Received: by mail-vs1-f52.google.com with SMTP id y26so339110vsq.8 for ; Tue, 01 Mar 2022 18:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w38NRVJaw/mUzTPc0uXiYZZSTKKexxda9JCXG6/MwxE=; b=sjom/chgdTmq+cYm1UgLyuUmK3bN4/Ae9SsLg0UYo+m4I62qBxesx2HfZ8EPbcpu0j /Wb6yfMtqJeViLmTXRIEBEr1XkC6VOCgGz+wa69UCt8itw7/C+2im9kAqYzcxB0qGZqv x81z62n3X2qWazkw9wqnJ8M8pnpcmNsQdAb5loWOexqeuaDZ9QR3fbpoLgYkZG54Wh9k +9p37eBQNEtyFb0MaWToasKRI58aNPWxxfzRMl9w9SHsJ48jU6RfcUSWTAGpnVOXD2Lx TebjBD0eKC5eaIR3ggLdwH602ymX1YVJoZJSEQ0PtIIZ0X4xiawKhUiXBwBsDm7SR7pD vH0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w38NRVJaw/mUzTPc0uXiYZZSTKKexxda9JCXG6/MwxE=; b=McCqQh5HnKH8K/6re+f4i4M2mtChG+olk9g1bbqyMFRqcSq2h/S6CjHZ+ZW1IFJRGC lRWvgw843WqvhHJvi9zwMtMrVmHwBhHs4XtTvaWj5uTCDjNwVAB8BFtFn54Y5+Xv9w8L 0RQS1SZUu7EpyitxK0TZZM38zXyEYokKhwCcWwbHAeza7I54WBVaFFTLZKlsmp9krJsl 81hHDcxzvd9Hqajv01PkxeywHXYtYBY12C2ulmLq8lew64LRnu3JR/J7v3mlfDtbvF0X Hpa84V6o+SjjGkniQ+BAnzU7ji7VinK1EuFf3iQndAWSwp6i93eEEbi8m9xU687ezReK +phw== X-Gm-Message-State: AOAM533z6eB+Yz8ebxb7B/eyMuH8aE/9/9l78yg6/7LyFFpnie8ApTpk UAfqr8NQTXezGibh6zImfmtnzXYYyGrbwrycNBq2qeNokVc= X-Google-Smtp-Source: ABdhPJyBrduSyMfZsqLI1SMq5yIYX+rE8dZYTT0Pmf0Qwh78Ky/6nM8nALCJ/o58EFYcwYt7eujopCYbpxnL1vMrunw= X-Received: by 2002:a67:e005:0:b0:303:b07f:9735 with SMTP id c5-20020a67e005000000b00303b07f9735mr12293776vsl.6.1646187355186; Tue, 01 Mar 2022 18:15:55 -0800 (PST) MIME-Version: 1.0 References: <20220302011959.0B3D818C087@mercury.lcs.mit.edu> In-Reply-To: <20220302011959.0B3D818C087@mercury.lcs.mit.edu> From: Warner Losh Date: Tue, 1 Mar 2022 19:15:43 -0700 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="0000000000008a3d1c05d932dc14" Subject: Re: [TUHS] Memory on Lion's v6 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: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000008a3d1c05d932dc14 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 1, 2022, 6:23 PM Noel Chiappa wrote: > > From: Andrew Hume > > > the actual configuration of Lions; PDP 11/40 was > > 128 Kbytes of core memory > > ... > > but note that because ... of addressing weirdness (the top 8KB were > > memory-mapped to I/O registers), Lions' PDP actually had 112KB of > main > > memory > > I think that '112KB' must be an error; the 8KB for the 'I/O page' (as DEC > eventually named ir, long after the rest of the world had started using the > term :-) were deducted from the _UNIBUS_ address space, meaning a UNIBUS > -11 > (the 'pure' UNIBUS -11's, i.e. other than the -11/70, -11/44, etc) could > have > a maximum of 248KB of main memory (which is on the UNIBUS). > > A pure UNIBUS -11 with 128KB of main memory (like Lions') has... 128KB of > main memory. The 'small memory management model' -11's (like the /40, /60, > /23, etc) can use at most 64KB of that _at any moment in time_ for user > processes (i.e. directly accessible by the CPU, in 'user' mode). > > (The kernel on such machines is basically retricted to 56KB at any moment > in > time, since one 'segment/page' - the terminology changed over time - has > to be > dedicated to the I/O page: the memory management control registers are in > that, so once the CPU can no longer 'see' them, it's stuck. Long, > potentially > interesting digression about, and ways to semi-work around that, elided, > unless people want to hear it.) > > > > From: Noel Chiappa > > > The -11/40 (as it was at first) that I had at LCS had, to start with, > > I'm pretty sure, 3 MM11-L units .. - i.e. 48KB. I know this sounds > > incredible, and I'm having a hard time believing it myself, wondering > > if my memory is failing with age > > It is: > > # size /lib/c0 > 13440+2728+10390=26558 (63676) > > ('c1' takes 14848+6950+2088=23886, FWIW.) So 'my' -11/40 must have had more > than 48KB. > > MINI-UNIX provides, on an -11/05 type machine with the maximum of 56KB of > addressable main memory (if you plugged in 64KB worth, the /05 CPU couldn't > 'see' the top 8KB of that), up to 32KB for a user process. So that will > just hold the stock V6 C compiler. > You made a comment that MINI-UNIX wasn't available outside of Bell... I meant to say that the AUUG newsletters talk about it. It features a letter asking for users of it to share patches. There was also an article about how to get it, though it was an offer to spin a tape for a photocopy of you Western Electric license... Warner I'm not now sure how much memory my -11 _did_ have initially, but it's not > important. > > Noel > --0000000000008a3d1c05d932dc14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 1, 2022, 6:23 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:<= br>
=C2=A0 =C2=A0 > From: Andrew Hum= e

=C2=A0 =C2=A0 > the actual configuration of Lions; PDP 11/40 was
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 128 Kbytes of core memory
=C2=A0 =C2=A0 > ...
=C2=A0 =C2=A0 > but note that because ... of addressing weirdness (the t= op 8KB were
=C2=A0 =C2=A0 > memory-mapped to I/O registers), Lions' PDP actually= had 112KB of main
=C2=A0 =C2=A0 > memory

I think that '112KB' must be an error; the 8KB for the 'I/O pag= e' (as DEC
eventually named ir, long after the rest of the world had started using the=
term :-) were deducted from the _UNIBUS_ address space, meaning a UNIBUS -1= 1
(the 'pure' UNIBUS -11's, i.e. other than the -11/70, -11/44, e= tc) could have
a maximum of 248KB of main memory (which is on the UNIBUS).

A pure UNIBUS -11 with 128KB of main memory (like Lions') has... 128KB = of
main memory. The 'small memory management model' -11's (like th= e /40, /60,
/23, etc) can use at most 64KB of that _at any moment in time_ for user
processes (i.e. directly accessible by the CPU, in 'user' mode).
(The kernel on such machines is basically retricted to 56KB at any moment i= n
time, since one 'segment/page' - the terminology changed over time = - has to be
dedicated to the I/O page: the memory management control registers are in that, so once the CPU can no longer 'see' them, it's stuck. Lon= g, potentially
interesting digression about, and ways to semi-work around that, elided, unless people want to hear it.)


=C2=A0 =C2=A0 > From: Noel Chiappa

=C2=A0 =C2=A0 > The -11/40 (as it was at first) that I had at LCS had, t= o start with,
=C2=A0 =C2=A0 > I'm pretty sure, 3 MM11-L units .. - i.e. 48KB. I kn= ow this sounds
=C2=A0 =C2=A0 > incredible, and I'm having a hard time believing it = myself, wondering
=C2=A0 =C2=A0 > if my memory is failing with age

It is:

=C2=A0 # size /lib/c0
=C2=A0 13440+2728+10390=3D26558 (63676)

('c1' takes 14848+6950+2088=3D23886, FWIW.) So 'my' -11/40 = must have had more
than 48KB.

MINI-UNIX provides, on an -11/05 type machine with the maximum of 56KB of addressable main memory (if you plugged in 64KB worth, the /05 CPU couldn&#= 39;t
'see' the top 8KB of that), up to 32KB for a user process. So that = will
just hold the stock V6 C compiler.

You made a comment that MINI-UNIX wasn= 9;t available outside of Bell... I meant to say that the AUUG newsletters t= alk about it. It features a letter asking for users of it to share patches.= There was also an article about how to get it, though it was an offer to s= pin a tape for a photocopy of you Western Electric license...

Warner=C2=A0
<= br>
I'm not now sure how much memory my -11 _did_ have initially, but it= 9;s not
important.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Noel
--0000000000008a3d1c05d932dc14--