The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: [TUHS] Re: forgotten versions
Date: Wed, 22 Jun 2022 22:18:58 -0400 (EDT)	[thread overview]
Message-ID: <20220623021858.C1BD918C095@mercury.lcs.mit.edu> (raw)

    > From: Dan Cross

    > I believe that's actually a menu

Hence the "erroneous _impression_" (emphasis added).

I'm curious as to how they decided which models to run which editions on.
Although V4 _ran_ on the /45, split I+D wasn't supported - for user or kernel
- until V6. (I'm assuming a number of things - both in the kernel, and
applications - started hitting the 64KB limit, which led to its support.)


Speaking of split I+D, there's an interesting little mystery in V6 that at
one point in time I thought involved split I+D - but now that I look closely,
apparently not. The mystery involves a 'tombstone' in the V6 buf.h:

  #define B_RELOC 0200 /* no longer used */

I had created (in my mind) an explanation what this is all about - but now
that I look, it's probably all wrong!

My explanation involves the slightly odd layout of the kernel in physical
memory, with split I+D; data below the code, at physical 0. This actually
makes a lot of sense; it means the virtual address of any data (e.g. a
buffer) is the same as its physical address (needed for DMA). It does require
the oddness of 'sysfix', to invert the order of code+data in the system
binary, plus odd little quirks in the assembler startup (e.g. copying the
code up to make room for BSS).

So I thought that B_RELOC was a hangover from a time, at the start of split
I+D, when data _wasn't_ at physical 0, so a buffer's virtual and phsyical
addresses differed.

But that must be wrong (at least in any simple way). B_RELOC was in buf.h as
of V4 - the first kernel version in C - with no split I+D. So my theory has
to be wrong.

However, I am unable to find any code in the V4 kernel which uses it! So
unless someone who remembers the very early PDP-11 kernel can enlighten us,
its purpose will always remain a mystery!

	Noel

             reply	other threads:[~2022-06-23  2:19 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23  2:18 Noel Chiappa [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-06-24  6:47 Paul Ruizendaal
2022-06-25 19:16 ` Anthony Martin
2022-06-25 20:45   ` Paul Ruizendaal
2022-06-27  0:57     ` Kevin Bowling
2022-06-22 12:06 Noel Chiappa
2022-06-23  0:02 ` Dan Cross
2022-06-18 19:55 Paul Ruizendaal
2022-06-18  0:35 Douglas McIlroy
2022-06-18  5:00 ` Kevin Bowling
2022-06-18  5:13   ` Adam Thornton
2022-06-18 16:58     ` Clem Cole
2022-06-18 17:18       ` Warner Losh
2022-06-18 17:57         ` Clem Cole
2022-06-17 14:50 Paul Ruizendaal
2022-06-16 23:06 [TUHS] " Rob Pike
2022-06-16 23:17 ` [TUHS] " Earl Baugh
2022-06-16 23:18 ` George Michaelson
2022-06-16 23:44   ` George Michaelson
2022-06-17  0:10     ` Larry McVoy
2022-06-17  7:20 ` Diomidis Spinellis
2022-06-17  7:33   ` Rob Pike
2022-06-17  8:34   ` arnold
2022-06-17 10:52 ` arnold
2022-06-18  7:05 ` Angelo Papenhoff
2022-06-19  7:50   ` Rob Pike
2022-06-19  8:17     ` Angelo Papenhoff
2022-06-19  8:53       ` Rob Pike
2022-06-19  9:02         ` Angelo Papenhoff
2022-06-19  9:14           ` arnold
2022-06-19  9:19             ` Angelo Papenhoff
2022-06-19  9:23               ` arnold
2022-06-19 11:37                 ` Matthias Bruestle
2022-06-19 14:47         ` Kenneth Goodwin
2022-06-19 16:27           ` Al Kossow
2022-06-19 18:32           ` Theodore Ts'o
2022-06-19 18:38             ` Dan Cross
2022-06-21 23:56               ` Jacob Moody
2022-06-22  0:13                 ` Larry McVoy
2022-06-22  0:48                   ` Rob Pike
2022-06-22  1:55                     ` George Michaelson
2022-06-22  2:10                       ` Bakul Shah
2022-06-22  2:14                       ` Jon Steinhart
2022-06-22  2:19                         ` Andrew Hume
2022-06-22  2:58                           ` Rob Pike
2022-06-22  3:09                             ` George Michaelson
2022-06-22  2:16                   ` Andrew Hume
2022-06-22  2:55                   ` Brad Spencer

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=20220623021858.C1BD918C095@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@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).