From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] pdp11 UNIX memory allocation.
Date: Tue, 6 Jan 2015 17:45:44 -0500 (EST) [thread overview]
Message-ID: <20150106224544.393BC18C091@mercury.lcs.mit.edu> (raw)
> From: Clem Cole <clemc at ccc.com>
> Depends the processor. For the 11/45 class processors, you had a 17th
> address bit, which was the I/D choice. For the 11/40 class you shared
> the instructions and data space.
To be exact, the 23, 24, 34, 35/40 and 60 all had a single shared space.
(I have no idea why DEC didn't put it in the 60 - probably helped kill that
otherwise intersting machine, with its UCS, early...). The 44, 45/50/55, 70,
73, 83/84, and 93/94 had split.
> From: random832 at fastmail.us
> the calling convention for PDP-11 Unix system calls read their
> arguments from directly after the trap instruction (which would mean
> that the C wrappers for the system calls would have to write their
> arguments there, even if assembly programs could have them hardcoded.)
Here's the code for a typical 'wrapper' (this is V6, not sure if V7 changed
the trap stuff):
_lseek:
jsr r5,csv
mov 4(r5),r0
mov 6(r5),0f
mov 8(r5),0f+2
mov 10.(r5),0f+4
sys indir; 9f
bec 1f
jmp cerror
1:
jmp cret
.data
9:
sys lseek; 0:..; ..; ..
Note the switch to data space for storing the arguments (at the 0: label
hidden in the line of data), and the 'indirect' system call.
> From: Ronald Natalie <ron at ronnatalie.com>
> Some access at the kernel level can be done with MFPI and MPFD
> instructions.
Unless you hacked your hardware, in which case it was possible from user mode
too... :-)
I remember how freaked out we were when we tried to use MFPI to read
instruction space, and it didn't work, whereupon we consulted the 11/45
prints, only to discover that DEC had deliberately made it not work!
> From: Ronald Natalie <ron at ronnatalie.com>
> After the changes to the FS, you'd get missing blocks and a few 0-0
> inodes (or ones where the links count was higher than the links). These
> while wasteful were not going to cause problems.
It might be worth pointing out that due to the way pipes work, if a system
crashed with pipes open, even (especially!) with the disk perfectly sync'd,
you'll be left with 0-0 inodes. Although as you point out, those were merely
crud, not potential sourdes of file-rot.
Noel
next reply other threads:[~2015-01-06 22:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-06 22:45 Noel Chiappa [this message]
2015-01-06 22:55 ` Clem Cole
-- strict thread matches above, loose matches on Subject: below --
2015-01-07 2:18 Noel Chiappa
2015-01-07 16:17 ` Clem Cole
[not found] <mailman.151.1420584979.3354.tuhs@minnie.tuhs.org>
2015-01-06 23:34 ` Johnny Billquist
2015-01-06 23:52 ` scj
2015-01-07 16:14 ` Clem Cole
2015-01-07 17:27 ` Dave Horsfall
[not found] <mailman.149.1420581544.3354.tuhs@minnie.tuhs.org>
2015-01-06 22:20 ` Johnny Billquist
2015-01-06 22:36 ` Ronald Natalie
2015-01-06 23:14 ` Johnny Billquist
2015-01-07 2:39 ` John Cowan
2015-01-07 2:59 ` Johnny Billquist
[not found] <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
2015-01-06 20:20 ` Johnny Billquist
2015-01-06 20:33 ` random832
2015-01-06 21:57 ` Ronald Natalie
2015-01-06 22:00 ` Clem Cole
2015-01-06 22:04 ` Ronald Natalie
2015-01-07 1:46 ` Dave Horsfall
2015-01-07 2:00 ` Ronald Natalie
2015-01-07 6:29 ` Dave Horsfall
2015-01-07 6:39 ` Warren Toomey
2015-01-07 10:06 ` Brantley Coile
2015-01-07 13:29 ` Jacob Ritorto
[not found] ` <CAC20D2PP1hGyYsep1yNtj9KO55a-V02+QHS+S7bX-4joJy222g@mail.gmail.com>
[not found] ` <1420583703.863814.210431037.61D6C6EC@webmail.messagingengine.com>
2015-01-06 22:36 ` random832
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=20150106224544.393BC18C091@mercury.lcs.mit.edu \
--to=jnc@mercury.lcs.mit.edu \
/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).