*This* is a computer!
http://archive.computerhistory.org/resources/text/EAI/EAI.HYDAC2400.1963.10…
A hybrid analogue/digital box, what could possibly go wrong? And check
out the dudes and dudess supporting it (except she'd better be careful
when moving her chair, in case she takes out a paper tape unit...).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> Dennis Ritchie's home pages have some info on this
Yeah, I'd read that - I was hoping for some actual technical info on the KS11,
though.
(I'm assuming he has given the name there correctly, or if his memory has
dropped a bit - a thing which human memories do! :-) - since I've never been
able to find a single mention of it, including in the Spare Module Handbook,
which covers other Special Systems products).
> I looked for (but did not find) information on what ""the classical
> PDP-10 style "hi-seg" "low-seg" memory mapping unit"" was.
The best description is in the DECSystem-10 Hardware Reference Manual (mine is
EK-10/20-HR-001, but alas that version appears not to be online - I'll scan my
copy and put it online when I get a chance.) This version:
http://pdp10.nocrew.org/docs/ad-h391a-t1.pdf
does appear to cover it: pp. 5-38 through 5-40 (pp. 352-354 of the PDF) for
the KA10, and pp. 5-15 to 5-30 (pp. 329-344) for the KI10.
The KA10 provided one (optionally) two base/bounds register pairs, where the
base register contains the location in real memory. With two pairs (the
second one applied to high user address space), the high part could be
write-protected, for sharing pure code.
The KI10 provided something similar to this, but more complicated; it included
paging, but also something called User 'Concealed', which allowed proprietary
subroutine packages to be used, while hidden from the rest of the user's code.
> Does anyone have an idea what PDP-10 MMU Dennis may have been referring
> to?
Almost certainly the KA10.
> Here my hypothesis would be that in kernel mode mapping was off, and
> that in user mode there were two segments, each with a base and limit
> into physical memory
Hard to say. Kernel mode might or might not have mapping, and User mode might
have provided one, or two, segments; the KA10 did have an option for
single-segment.
> this setup has an echo in how the later KL-11 MMU was used.
Sorry, what's a KL-11? The only 'KL11' I know of is the serial line board
(M780) which was the predecessor to the DL11.
Noel
Finally took a look at the V1 source.
Referring to http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s
Toward the end of the sysexec function there is:
cmp core,$405 / br .+14 is first instruction if file is
/ standard a.out format
bne 1f / branch, if not standard format
mov core+2,r5 / put 2nd word of users program in r5; number of
/ bytes in program text
sub $14,r5 / subtract 12
cmp r5,u.count /
bgt 1f / branch if r5 greater than u.count
mov r5,u.count
jsr r0,readi / read in rest of user's program text
add core+10,u.nread / add size of user data area to u.nread
br 2f
1:
jsr r0,readi / read in rest of file
2:
mov u.nread,u.break / set users program break to end of
/ user code
add $core+14,u.break / plus data area
jsr r0,iclose / does nothing
br sysret3 / return to core image at $core
$core is equated to 040000 in another file (u0.s). In V1 apparently the a.out header was 6 words (http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man5/a.out.5), not 8, and hence the magic for a standard executable was 0405. It was already used as magic to distinguish a.out format files from other executables. It also shows that indeed 'exec' jumped to the first word of the header (at location $core).
From this I don't think we will find code for the KS-11 in the V1 source. The file http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u3.s also seems to support a LSX /MX like approach where each process switch equates a swap.
I'd say that the lost V2 is where memory protection first appeared in Unix, i.e. 1972.
Paul
PS Sorry for writing 'V0' earlier -- I meant V1 all along.
On 2016-12-08 18:18, Paul Ruizendaal <pnr(a)planet.nl> wrote:
>
>>> DEC's Custom Special Systems (CSS) group .. build a simple base/limi
>>> register device, soon after the 11/20 was released.> ... So an early
>>> version of after the original 11/20 port from the PDP-7 had this
>>> however.....
>> Oh, right, I'd forgotten about that: the KS-11 - I've previously enquired to
>> see if anyone had _any_ documentation for this, but so far, nada.
> I was looking for that a few years back. Dennis Ritchie's home pages have
> some info on this (https://www.bell-labs.com/usr/dmr/www/odd.html).
> At the bottom of that page he writes:
>
> ""Back around 1970-71, Unix on the PDP-11/20 ran on hardware that not only did not support virtual memory, but didn't support any kind of hardware memory mapping or protection, for example against writing over the kernel. This was a pain, because we were using the machine for multiple users. When anyone was working on a program, it was considered a courtesy to yell "A.OUT?" before trying it, to warn others to save whatever they were editing.
> [..snip..]
> We knew the PDP-11/45, which did support memory mapping and protection for the kernel and other processes, was coming, but not instantly; in anticipation, we arranged with Digital Special Systems to buy a PDP-11/20 with KS-11 add-on. This was an extra system unit bolted to the processor that made it distinguish kernel from user mode, and provided a classical PDP-10 style "hi-seg" "low-seg" memory mapping unit. I seem to recall that maybe 6 of these had been made when we ordered it.""
>
> My hypothesis is that the very first versions of Unix were using a memory scheme similar to that used in the later LSX and MX derivatives: the kernel resides in lower memory and the user program in upper memory; each process switch implied a swap. Disclaimer: I have not studied the V0 source to verify this hypothesis.
>
> When this topic had my interest I looked for (but did not find) information on what ""the classical PDP-10 style "hi-seg" "low-seg" memory mapping unit"" was. Here my hypothesis would be that in kernel mode mapping was off, and that in user mode there were two segments, each with a base and limit into physical memory -- and that this setup has an echo in how the later KL-11 MMU was used.
>
> Does anyone have an idea what PDP-10 MMU Dennis may have been referring to?
If you read the Wikipedia page about the PDP-10, you'd find the answer.
Basically, kernel mode uses physical memory. User mode have a low
segment and a high segment. This is decided by the high bit of the address.
For each segment, there is a base register and a length register.
Commonly, the low segment stored read/write data, while the high segment
could be shared between processes, and have readonly data/code.
But you could play in other ways with it, if you wanted to.
Essex MUD, as far as I remember, had the game data in a shared hiseg,
which could be written by the program.
So your guessing is pretty good. Not sure I'd say this is similar to how
the later PDP-11 MMU works, though. But I can see someone making the
comparison, since the PDP-11 pages can vary in size, within limits.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> From: Clem Cole
> DEC's Custom Special Systems (CSS) group .. build a simple base/limi
> register device, soon after the 11/20 was released.> ... So an early
> version of after the original 11/20 port from the PDP-7 had this
> however.....
Oh, right, I'd forgotten about that: the KS-11 - I've previously enquired to
see if anyone had _any_ documentation for this, but so far, nada.
> I would look at Warren's First Edition work to see if there were dregs
> of this in that code base
Alas, I'd already had that idea (to try and at least re-create a programming
spec, at least, for the KS11). There do not seem to be any traces there,
perhaps because that code came from a document entitled "Preliminary Release
of Unix Implementation", which argues that it's a very early 'version' of V0
(the early 'versions' weren't very formal, there was a continuous process of
change/improvement going on, apparently).
> It is also noted that the 45 class system (45/55/70/44) had "17th"
> address bit - i.e. split I/D space. I believe that this is when "magic
> numbers" were really introduced so that could be supported.
No, they came in first for 'pure text' (0410):
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/sys1.c
which I would expect arrived to minimize swapping on machines with small
amounts of real memmory.
Support for user split-I/D (411) didn't arrive until Version 6:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c
although IIRC split I/D in the kernel was supported supported slightly
before it was in user - although V5 didn't:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/conf/mch.s
so it couldn't have been much earlier than V6.
Noel
Which version of Unix first ran on a computer with virtual addressing (address translation) so that a process with non-position independent code (PIC) can be loaded anywhere in RAM that the kernel decided to put it, and memory protection such that no process could accidentally or deliberately access RAM not allocated to it by the kernel (or a SIGSEGV would be delivered to it)?
Put another way, when did Unix processes stop playing Core War with each other? (OK, so long as no more than one is resident at a time, they can't play Core War with each other, but there still needs to be a mechanism to protect the kernel from inadvertent (or advertent) pointer use).
Which is to say, when did Unix run on (and properly use) computers with memory management units (MMU)?
My guess from a quick look at the history of the DEC PDP-11 is that the target computer was likely a PDP-11/35 or PDP-11/40 with a KT11-D "memory management" module.
One imagines that many pointer mistakes (bugs) in assembly or C were discovered and squashed in that version, modulo the historical unhappiness resulting from address zero containing a zero if dereferenced ("NULL pointers") in process address space.
What year did that come about?
By the time I got to Unix (2.8BSD on the Cory Hall DEC PDP-11/70), those features (virtual addresses, memory protection from the kernel) had apparently been part of Unix for a long time - certainly earlier than Version 6.
This is distinct from demand-paged virtual memory which so far as I know was developed on the DEC VAX-11.
curious,
Erik <fair(a)netbsd.org>
> From: "Erik E. Fair" <f
> One imagines that many pointer mistakes (bugs) in assembly or C were
> discovered and squashed in that version, modulo the historical
> unhappiness resulting from address zero containing a zero if
> dereferenced ("NULL pointers") in process address space.
PS: PDP-11 Unix didn't, I think, do much (anything?) to solve the null pointer
problem. (This is for early C versions; I don't know about the later BSD
ones.)
Location 0 was a usable address for both read and write for everything except
'pure-text' (0410 magic word) processes; in those it was only legal for
read. Address 0 mostly did not contain a 0, either; for C programs using the
stock run-time, it contained a 'setd' instruction, except in split I+D
processes, in which case data space location 0 probably (I'm too busy to spin
up my V6 emulator to check) contained some of the program's initialized data
(unless special arrangements had been made).
Noel
> From: "Erik E. Fair"
> Which version of Unix first ran on a computer with virtual addressing
That would be the first version to run on the PDP-11/45; I'm not sure which one
that was, there's not enough left of Version 2 or Version 3 to see; Version 4
definitely ran on the 11/45:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/45.s
> My guess from a quick look at the history of the DEC PDP-11 is that the
> target computer was likely a PDP-11/35 or PDP-11/40 with a KT11-D
> "memory management" module.
No, they came after the -11/45 (with the KT11-C MMU).
> What year did that come about?
They got one of the first -11/45's, per a Unix history document I'm too busy
to dig up, so 1972.
Noel
I'm not sure if my other reply got though, so I'll try again...
I found the source to the BBN stack in the CSRG CD's it's on CD 4
/sys/deprecated/bbnnet
LINT.bbn 08-Aug-2016 06:37 3.5K
NOTES 08-Aug-2016 06:37 4.6K
RELAY.bbn 08-Aug-2016 06:37 1.2K
SCCS/ 08-Aug-2016 06:37 -
fsm.h 08-Aug-2016 06:37 1.2K
fsmdef.h 08-Aug-2016 06:37 9.6K
hmp.c 08-Aug-2016 06:37 12K
hmp.h 08-Aug-2016 06:37 3.2K
hmp_subr.c 08-Aug-2016 06:37 6.5K
hmp_traps.c 08-Aug-2016 06:37 3.5K
hmp_traps.h 08-Aug-2016 06:37 2.7K
hmp_var.h 08-Aug-2016 06:37 1.4K
ic_output.c 08-Aug-2016 06:37 5.7K
icmp.c 08-Aug-2016 06:37 17K
icmp.h 08-Aug-2016 06:37 3.3K
in.c 08-Aug-2016 06:37 12K
in.h 08-Aug-2016 06:37 2.0K
in_pcb.c 08-Aug-2016 06:37 11K
in_pcb.h 08-Aug-2016 06:37 1.9K
in_proto.c 08-Aug-2016 06:37 4.9K
in_var.h 08-Aug-2016 06:37 2.2K
ip.h 08-Aug-2016 06:37 3.3K
ip_input.c 08-Aug-2016 06:37 29K
ip_output.c 08-Aug-2016 06:37 14K
ip_usrreq.c 08-Aug-2016 06:37 3.8K
macros.h 08-Aug-2016 06:37 4.4K
net.h 08-Aug-2016 06:37 2.4K
nopcb.h 08-Aug-2016 06:37 318
raw_input.c 08-Aug-2016 06:37 9.4K
rdp.h 08-Aug-2016 06:37 15K
rdp_cksum.s 08-Aug-2016 06:3
7 4.4K
rdp_fsm.c 08-Aug-2016 06:37 4.5K
rdp_input.c 08-Aug-2016 06:37 9.6K
rdp_macros.h 08-Aug-2016 06:37 7.9K
rdp_prim.c 08-Aug-2016 06:37 13K
rdp_states.c 08-Aug-2016 06:37 34K
rdp_subr.c 08-Aug-2016 06:37 8.4K
rdp_usrreq.c 08-Aug-2016 06:37 21K
seq.h 08-Aug-2016 06:37 415
sws.h 08-Aug-2016 06:37 326
tcp.h 08-Aug-2016 06:37 8.6K
tcp_input.c 08-Aug-2016 06:37 12K
tcp_prim.c 08-Aug-2016 06:37 9.8K
tcp_procs.c 08-Aug-2016 06:37 28K
tcp_states.c 08-Aug-2016 06:37 20K
tcp_usrreq.c 08-Aug-2016 06:37 22K
udp.c 08-Aug-2016 06:37 5.2K
udp.h 08-Aug-2016 06:37 1.1K
udp_usrreq.c 08-Aug-2016 06:37 7.0K
I've been meaning to try to try to manually mash stuff together but just
haven't gotten around to it.
> ----------
> From: Paul Ruizendaal
> Sent: Thursday, December 1, 2016 4:30 PM
> To: tuhs(a)minnie.tuhs.org
> Subject: [TUHS] looking for 4.1a BSD full kernel source
>
>
> Hi,
>
> I'm trying to find out exactly what was in the 4.1a BSD distribution, as
> far as the kernel is concerned. The image in the CSRG archive comes from a
> tape that had a hard read error and does not include any kernel sources.
> Some of the kernel files were already covered by SCCS around that time,
> but not everything. My main focus is to understand tcp/ip networking in
> 4.1a and whether the kernel could be built with either the Berkeley or the
> BBN network stack.
>
> Does anybody know where I could find a full set of kernel sources for the
> 4.1a BSD kernel?
>
> Many thanks in advance!
>
> Paul
>
Hi
I am sure there must have been an email about this if so, I do apologies.
The below link is from Diomidis Spinellis work, I remember seeinng an email
from him a few months ago requesting some information about the history of
BSD. Looking at it, he has done some amazing work. I look forward to
playing with 386BSD!
https://github.com/dspinellis/unix-history-repo
