The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@minnie.tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [TUHS] Memory on Lion's v6
Date: Tue,  1 Mar 2022 20:19:59 -0500 (EST)	[thread overview]
Message-ID: <20220302011959.0B3D818C087@mercury.lcs.mit.edu> (raw)

    > 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.

I'm not now sure how much memory my -11 _did_ have initially, but it's not
important.

	Noel

             reply	other threads:[~2022-03-02  1:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02  1:19 Noel Chiappa [this message]
2022-03-02  2:15 ` Warner Losh
  -- strict thread matches above, loose matches on Subject: below --
2022-03-02  2:26 Noel Chiappa
2022-03-01  0:44 Noel Chiappa
2022-02-28  5:48 Will Senn
2022-02-28  6:09 ` Warner Losh
2022-02-28 15:48 ` Clem Cole
2022-02-28 23:27   ` Andrew Hume
2022-03-01 15:31     ` Andrew Hume
2022-03-01  1:25 ` Bakul Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220302011959.0B3D818C087@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).