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