TUHS

tuhs@tuhs.org

19 participants
6471 discussions

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > This is where I disagree. The problem is that the chunks in the PDP-11 > do not describe things from a zero offset, while a segment do. Only > chunk 0 is describing addresses from a 0 offset. And exactly which chunk > is selected is based on the virtual address, and nothing else. Well, you have something of a point, but... it depends on how you look at it. If you think of a PDP-11 address as holding two concatenated fields (3 bits of 'segment' and 13 bits of 'offset within segment'), not so much. IIRC there are other segmented machines that do things this way - I can't recall the details of any off the top of my head. (Well, there the KA10/KI10, with their writeable/write-protected 'chunks', but that's a bit of a degenerate case. I'm sure there is some segmented machine that works that way, but I can't recall it.) BTW, this reminds me of another key differentiator between paging and segments, which is that paging was originally _invisible_ to the user (except for setting the total size of the process), whereas segmentation is explicitly visible to the user. I think there is at least one PDP-11 OS which makes the 'chunks' visible to the user - MERT (and speaking of which, I need to get back on my project of trying to track down source/documentation for it). > Demand paging really is a separate thing from virtual memory. It's a > very bad thing to try and conflate the two. Really? I always worked on the basis that the two terms were synonyms - but I'm very open to the possibility that there is a use to having them have distinct meanings. I see a definition of 'virtual memory' below, but what would you use for 'paging'? Now that I think about it, there are actually _three_ concepts: 'virtual memory', as you define it; what I will call 'non-residence' - i.e. a process can run without _all_ of its virtual memory being present in physical memory; and 'paging' - which I would define as 'use fixed-size blocks'. (The third is more of an engineering thing, rather than high-level architecture, since it means you never have to 'shuffle' core, as systems that used variable-sized things seem to.) 'Non-residence' is actually orthogonal to 'paging'; I can imagine a paging system which didn't support non-residence, and vice versa (either swapping the entire virtual address space, or doing it a segment at a time if the system has segments). > There is nothing about virtual memory that says that you do not have to > have all of your virtual memory mapped to physical memory when the > process is running. True. > Virtual memory is just *virtual* memory. It's not "real" or physical in > the sense that it has a dedicated location in physical memory, which > would be the same for all processes talking about that memory > address. Instead, each process has its own memory, which might be mapped > somewhere in physical memory, but it might also not be. OK so far. > each process would have to be aware of all the other processes that use > memory, and make sure that no two processes try to use the same memory, > or chaos ensues. There's also the System 360 approach, where processes share a single address space (physical memory - no virtual memory on them!), but it uses protection keys on memory 'chunks' (not sure of the correct IBM term) to ensure that one process can't tromp on another's memory. >> a memory management device for the PDP-11 which provided 'real' paging, >> the KT11-B? > have never read any technical details. Interesting read. Yes, we were lucky to be able to retrieve detailed info on it! A PDP-11/20 sold on eBay with a fairly complete set of KT11-B documentation, and allegedly a "KT11-B" as well, but alas, it turned out to 'only' be an RK11-C. Not that RK11-C's aren't cool, but on the 'cool scale' they are like 3, whereas a KT11-B would have been, like, 17! :-) Still, we managed to get the KT11-B 'manual' (such as it is) and prints online. I'd love to find out equivalent detail for the KT11-A, but I've never seen anything on it. (And I've appealed before for the KS11, which an early PDP-11 Unix apparently used, but no joy.) > But how do you then view modern architectures which have different sized > pages? Are they no longer pages then? Actually, there is precedent for that. The original Multics hardware, the GE-645, supported two page sizes. That was dropped in later machines (the Honeywell 6000's) since it was decided that the extra complexity wasn't worth it. I don't have any problem with several different page sizes, _if it makes engineering sense to support them_. (I assume that the rationale for their re-introduction is that in the age of 64-bit machines, page tables for very large 'chunks' can be very large if pages of ~1K or so are used, or something like.) It does make real memory allocation (one of the advantages of paging) more difficult, since there would now be small and large page frames. Although I suppose it wouldn't be hard to coalesce them, if there are only two sizes, and one's a small power-of-2 multiple of the other - like 'fragments' in the Berkeley Fast File System for BSD4.2. I have a query, though - how does a system with two page sizes know which to use? On Multics (and probably on the x86), it's a per-segment attribute. But on a system with a large, flat address space, how does the system know which parts of it are using small pages, and which large? Noel

6 years, 12 months

Re: [TUHS] /dev/drum

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > Gah. If I were to try and collect every copy made, it would be quite a > collection. Well, just the 'processor handbook's (the little paperback things), I have about 30. (If you add devices, that probably doubles it.) I think my collection is complete. > So there was a total change in terminology early in the 11/45 life, it > would appear. I wonder why. ... I probably would not blame some market > droids. I was joking, but also serious. I really do think it was most likely marketing-driven. (See below for why I don't think it was engineering-driven, which leaves....) I wonder if there's anything in the DEC archives (a big chunk of which are now at the CHM) which would shed any light? Some of the archives are online there, e.g.: http://www.bitsavers.org/pdf/dec/pdp11/memos/ but it seems to be mostly engineering (although there's some that would be characterized as marketing). > one of the most important differences between segmentation and pages are > that with segmentation you only have one contiguous range of memory, > described by a base and a length register. This will be a contiguous > range of memory both in virtual memory, and in physical memory. I agree completely (although I extend it to multiple segments, each of which has the characterstics you describe). Which is why I think the original DEC nomenclature for the PDP-11's memory management was more appropriate - the description above is _exactly_ the functionality provided for each of the 8 'chunks' (to temporarily use a neutral term) of PDP-11 address space, which don't quack like most other 'pages' (to use the 'if it quacks like a duck' standard). One query I have comes from the usual goal of 'virtual memory' (which is the concept most tightly associated with 'pages'), which is to allow a process to run without all of its pages in physical memory. I don't know much about PDP-11 DEC OS's, but do any of them do this? (I.e. allow partial residency.) If not, that would be ironic (in view of the later name) - and, I think, evidence that the PDP-11 'chunks' aren't really pages. BTW, did you know that prior to the -11/45, there was a memory management device for the PDP-11 which provided 'real' paging, the KT11-B? More here: http://gunkies.org/wiki/KT11-B_Paging_Option I seem to recall some memos in the memo archive that discussed it; I _think_ it mentioned why they decided not to go that way in doing memory management for the /45, but I forget the details? (Maybe the performance hit of keeping the page tables in main memory was significant?)_ > With segmentation you cannot have your virtual memory split up and > spread out over physical memory. Err, Multics did that; the process' address space was split up into many segments (a true 2-dimensional naming system, with 18 bits of segment number), which were then split up into pages, for both virtual memory ('not all resident'), and for physical memory allocation. Although I suppose one could view that as two separate, sequential steps - i.e. i) the division into segments, and ii) the division of segments into pages. In fact, I take this approach in describing the Multics memory system, since it's easier to understand as two independent things. > You can also have "holes" in your memory, with pages that are invalid, > yet have pages higher up in your memory .. Something that is impossible > with segmentation, since you only have one set of registers for each > memory type (at most) in a segmented memory implementation. You seem to be thinking of segmentation a la Intel 8086, which is a hack they added to allow use of more memory (although I suspect that PDP-11 chunks were a hack of a similar flavour). At the time we are speaking of, the Intel 8086 did not exist (it came along quite few years later). The systems which supported segmentation, such as Multics, the Burroughs 5000 and successors, etc had 'real' segmentation, with a full two-dimensional naming system for memory. (Burroughs 5000 segment numbers were 10 bits wide.) > I mean, when people talk about segmented memory, what most everyone > today thinks of is the x86 model, where all of this certainly is true. It's also (IMNSHO) irrelevant to this. Intel's brain-damage is not the entirety of computer science (or shouldn't be). (BTW, later Intel xx86 machines did allow you have to 'holes' in segments, via the per-segment page tables.) > it would be very wrong to call what the PDP-11 have segmentation The problem is that what PDP-11 memory management does isn't really like _either_ segmentation, or paging, as practised in other machines. With only 8 chunks, it's not like Multics etc, which have very large address spaces split up into many segments. (And maybe _that_'s why the name was changed - when people heard 'segments' they thought 'lots of them'.) However, it's not like paging on effectively all other systems with paging, because in them paging's used to provide virtual memory (in the sense of 'the process runs with pages missing from real memory'), and to make memory allocation simple by use of fixed-size page frames. So any name given PDP-11 'chunks' is going to have _some_ problems. It just thing 'segmentation' (as you defined it at the top) is a better fit than the alternative... Noel

6 years, 12 months

Utility privs

by Ron Natalie

Depending on the system PS may or may not need to be setuid to work by non-root users. Ping needs to be setuid because it uses raw sockets which are restricted (much like opening listens on low number ports) in many systems.

6 years, 12 months

Re: [TUHS] rm command

by jnc＠mercury.lcs.mit.edu

> From: William Corcoran > I think it's a bit more interesting to uncover why rm does not remove > directories by default thereby obviating the need for rmdir On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is setuid-root, since it has to do special magic (writing into directory files, etc). Given that, it made sense to have 'rm' run with the least amount of privilege needed to do its job. Noel

6 years, 12 months

Re: [TUHS] /dev/drum

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > For 1972 I only found the 11/40 handbook. I have a spare copy of the '72 /45 handbook; send me your address, and I'll send it along. (Every PDP-11 fan should have a copy of every edition of every model's handbooks... :-) In the meantime, I'm too lazy to scan the whole thing, but here's the first page of Chapter 6 from the '72: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/tmp/PDP11145ProcHbook72pg6-1.j… > went though the 1972 Maintenance Reference Manual for the 11/45. That > one also says "page". :-) There are a few remnant relics of the 'segment' phase, e.g. here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s which has this comment: / turn on segmentation Also, if you look at the end, you'll see SSR0, SSR1 etc (as per the '72 handbook), instead of the later SR0, SR1, etc. Noel

6 years, 12 months

Re: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)

by jnc＠mercury.lcs.mit.edu

> From: Paul Winalski <paul.winalski(a)gmail.com> > Regarding the Winchester code name, I've argued about this with Clem > before. Clem claims that the code name refers to various advances in > disk technology first released in the 3330's disk packs. Wikipedia and > my own memory agree with you that Winchester referred to the 3340. And you believe anything in Wikipedia? If so, I have a bridge to sell you! :-) But, in this case, it's correct. According to "IBM's 360 and Early 370 Computers" (Pugh, Johnson and Palmer - a very good book, BTW), pg. 507, the first Winchester was the 3340. The confusion comes from the fact that it had two spindles, each of 30MB capacity, making it a so-called "30-30" system - that being the name of Winchester's rifle. Noel

6 years, 12 months

Re: [TUHS] /dev/drum

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist >> Well, the 1972 edition of the -11/45 processor handbook ^^ > It would be nice if you actually could point out where this is the > case. I just went through that 1973 PDP-11/45 handbook ^^ Yes, the '73 one (red/purple cover) had switched. It's only the '72 one (red/white cover) that says 'segments'. Noel

7 years

Happy birthday, computer mouse!

by Dave Horsfall

Blimey, but I nearly missed this one (I was sick in bed). On this day in 1981, some little company called Xerox PARC introduced something called a "mouse" (mostly because it has a tail), but I'm struggling to find more information about it; wasn't there a photo of a big boxy device? -- Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW) People who fail to / understand security / surely will suffer. (tks: RichardM)

7 years

Re: [TUHS] /dev/drum

by Johnny Billquist

On 2018-04-26 04:00, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Johnny Billquist > > > if you hadn't had the ability for them to be less than 8K, you wouldn't > > even try that argument. > > Well, the 1972 edition of the -11/45 processor handbook called them segments..:-) I think we had this argument before as well. It would be nice if you actually could point out where this is the case. I just went through that 1973 PDP-11/45 handbook, and all it says are "page" everywhere I look. I also checked the 1972 PDP-11/40 handbook, and except for one mention of "segment" in the introduction part of the handbook, which is not even clear if it actually specifically refers to the MMU capabilities, that handbook also use the word "page" everywhere. I also checked the PDP-11/20 handbook, but that one does not even cover any MMU, so no mention of neither "page" nor "segment" can be found. > I figure some marketing droid found out that 'paging' was the new buzzword, and > changed the name...:-) :-) Somehow I doubt it, but looking forward to your references... :-) 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

7 years

/dev/drum

by Tim Bradshaw

I am sure I remember a machine which had this (which would have been running a BSD 4.2 port). Is my memory right, and what was it for (something related to swap?)? It is stupidly hard to search for (or, alternatively, there are just no hits and the memory is false). --tim

7 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS