> 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 figure some marketing droid found out that 'paging' was the new buzzword, and
changed the name... :-) :-)
Noel
On 2018-04-26 00:55, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote:
> > From: Johnny Billquist
>
> > PDP-11 have 8K pages.
>
> Segments.:-) (This is an old argument between Johnny and me, I'm not trying
> to re-open it, just yanking his chain...:-)
:-)
And if you hadn't had the ability for them to be less than 8K, you
wouldn't even try that argument. But just because the hardware gives you
some extra capabilities, you suddenly want to associate them with a
technology that really gives you much less capabilities.
Either way, the next page always start at the next 8K boundary.
> > On a PDP-11, all your virtual memory was always there when the process
> > was on the CPU
>
> In theory, at least (I don't know of an OS that made use of this), didn't the
> memory management hardware allow the possibility to do demand-paging? I note
> that Access Control Field value 0 is "non-resident".
Oh yes. You definitely could do demand paging based on the hardware
capabilities.
> Unix kinda-sorta used this stuff, to automatically extend the stack when the
> user ran off the end of it (causing a trap).
Ah. Good point. The same is also true for brk, even though that is an
explicit request to grow your memory space at the other side.
DEC OSes had the brk part as well, but stack was not automatically
extended if needed. DEC liked to have the stack at the low end of
address space, and have hardware that trapped if the stack grew below
400 (octal).
> > you normally did not have demand paging, since that was not really
> > gaining you much on a PDP-11
>
> Especially on the later machines, with more than 256KB of hardware main
> memory. Maybe it might have been useful on the earlier ones (e.g. the -11/45).
Yeah, it would actually probably have been more useful on an 11/45.
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: Johnny Billquist
> PDP-11 have 8K pages.
Segments. :-) (This is an old argument between Johnny and me, I'm not trying
to re-open it, just yanking his chain... :-)
> On a PDP-11, all your virtual memory was always there when the process
> was on the CPU
In theory, at least (I don't know of an OS that made use of this), didn't the
memory management hardware allow the possibility to do demand-paging? I note
that Access Control Field value 0 is "non-resident".
Unix kinda-sorta used this stuff, to automatically extend the stack when the
user ran off the end of it (causing a trap).
> you normally did not have demand paging, since that was not really
> gaining you much on a PDP-11
Especially on the later machines, with more than 256KB of hardware main
memory. Maybe it might have been useful on the earlier ones (e.g. the -11/45).
Noel
On 2018-04-25 23:14, Paul Winalski <paul.winalski(a)gmail.com> wrote:
> On 4/25/18, Ronald Natalie
> <ron(a)ronnatalie.com> wrote:
>> The fun argument is what is Virtual Memory. Typically, people align that
>> with paging but you can stretch the definition to cover paging.
>> This was a point of contention in the early VAX Unix days as the ATT (System
>> III, even V?) didn’t support paging on the VAX where as BSD did.
> In my book, virtual memory is any addressing scheme where the
> addresses that the program uses are different from the physical memory
> addresses. Nowadays most OSes use a scheme where each process has its
> own virtual address space, and virtual memory is demand-paged from
> backing store on disk. But there have been other schemes.
Yeah...
> Some PDP-11 models had a virtual addressing feature called PLAS
> (Program Logical Address Space). The PDP-11 had 16-bit addressing,
> allowing for at most 64K per process. To take advantage of physical
> memory larger than 64K, PLAS allowed multiple 64K virtual address
> spaces to be mapped to the larger physical memory. Sort of the
> reverse of the usual virtual addressing scheme, where there is more
> virtual memory than physical memory.
Note that PLAS is not a PDP-11 hardware thing. PLAS was the name for the
mechanism provided by the OS for applications to be able to access more
than 64K of memory while still be limited by the virtual address space
limit of 64K.
PLAS is in one way very similar to mmap, except that it's not backed by
a file. But you create a memory region though the OS (giving it a name
and a size, which can be more than 64K), and then you can map to it,
specifying the offset into it and window size, as well as where to map
to in your virtual address space.
This is realized by just using the pages of the MMU of the PDP-11 map to
different parts and things.
Any OS that had the PLAS capability by necessity had to have an MMU,
which was the hardware part that allowed this to be implemented.
So, all PDP-11s with an MMU could allow the OS running on it to provide
the PLAS capabilities.
A PDP-11 in general is "reversed" in that the physical address space is
much larger than the virtual one. Although, the same was also true on
the VAX in the last iteration where the NVAX implementation allowed for
a 34 bit physical address, while the virtual address space was still
only 32 bits.
But that doesn't make the virtual memory any less virtual.
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: Johnny Billquist
> I don't know exactly why DEC left the last three tracks unused. Might
> have been for diagnostic tools to have a scratch area to play with.
> Might have been that those tracks were found to be less reliable. Or
> maybe something completely different. But it was not for bad block
> replacement, as DEC didn't even do that on RK05
The "pdp11 peripherals handbook" (1975 edition at least, I can't be bothered
to check them all) says, for the RK11:
"Tracks/surface: 200+3 spare"
and for the RP11:
"Tracks/surface: 400 (plus 6 spares)"
which sounds like it could be for bad block replacement, but the RP11-C
Maintenance Manual says (pg. 3-10) "the inner-most cylinders 400-405 are only
used for maintenance".
Unix blithely ignored all that, and used every block available on both the
RK11 and RP11.
Noel
On 2018-04-25 16:39, arnold(a)skeeve.com wrote:
> Tim Bradshaw<tfb(a)tfeb.org> wrote:
>
>> Do systems with huge pages page in the move-them-to-disk sense I wonder?
>> I assume they don't in practice because it would be insane but I wonder
>> if the VM system is in theory even willing to try.
> Why not? If there's enough backing store availble?
>
> Note that many systems demand page-in the code section straight out of the
> executable, so if some of those pages aren't needed, they can just
> be released. And said pages can be shared among all processes running
> the same executable, for further savings.
Right.
>> Something I never completely understood in the paging vs swapping
>> thing was that I think that systems which could page (well, 4.xBSD in
>> particular) would*also* swap if pushed. I think the reason for that was
>> that, if you were really short of memory, swapping freed up the process
>> structure and also the page tables &c for the process, which would still
>> be needed even if all its pages had been evicted. Is that right?
> It depends upon the system. Some had pageable page tables, which is
> pretty hairy. Others didn't. I don't remember what 4BSD did on the
> Vax, but I suspect that the page tables and enough info to find everything
> on swap stayed in kernel memory. (Where's Chris Torek when you need
> him?:-)
The pages tables describing the users memory space are themselves
located in virtual memory on the VAX, so they can be paged out without
problem. If you refer to an entry in the user page table, and that page
itself is paged out, you'll get a page fault for the system page table,
so you'll need to page in that page of the system.
But I seem to remember 4BSD (as well as NetBSD) keep all of the kernel
in physical memory all the time, and don't page the kernel parts,
including process page tables.
> But yes, swapping was generally used to free up large amounts of memory
> if under heavy load.
Paging would free up the same amount of memory, if we talk about the
memory used by the process itself. However, there are various meta data
in the kernel itself that is needed for a process, which will remain in
memory even if no pages are in memory. Swapping will also move
non-essential kernel structures out to disk for the process, in addition
to the pages. Thus, there is a difference between swapping and paging.
The whole process context for example. Which includes both the page
tables as well as the kernel mode stack for the process, processor
registers, and possibly also open file contexts, and probably some other
things I'm forgetting now.
Very little needs to be kept in memory for a process if you are not
interested in resuming it on short notice.
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
I came across this yesterday:
> Fun fact: according to unsubstantiated UNIX lore, "rm" is NOT short-hand
> for "remove" but rather, it stands for the initials of the developer that wrote
> the original implementation, Robert Morris.
>
> https://news.ycombinator.com/item?id=16916565
I was curious if there's any truth to it. I found
http://minnie.tuhs.org/cgi-bin/utree.pl and was poking around but
couldn't determine when the rm command came about.
Thoughts?
--
Eric Blood
winkywooster(a)gmail.com
On 2018-04-25 16:39, Ronald Natalie<ron(a)ronnatalie.com> wrote:
>
>> On Apr 24, 2018, at 9:27 PM, Dan Stromberg<drsalists(a)gmail.com> wrote:
>>
>> On Sun, Apr 22, 2018 at 2:51 PM, Dave Horsfall<dave(a)horsfall.org> wrote:
>>> Now, how many youngsters know the difference between paging and swapping?
>> I'm a mere 52, but I believe paging is preferred over swapping.
>>
>> Swapping is an entire process at a time.
>>
>> Paging is just a page of memory at a time - like 4K or something thereabout.
> Early pages were 1K.
What machines are we talking about then?
PDP-11 have 8K pages. VAX have 512 byte pages, if we talk about hardware.
(And yes, I know pages on PDP-11s are not fixed in size, but if you want
the page to go right up to the next page, it's 8K.)
> The fun argument is what is Virtual Memory. Typically, people align that with paging but you can stretch the definition to cover paging.
> This was a point of contention in the early VAX Unix days as the ATT (System III, even V?) didn’t support paging on the VAX where as BSD did.
> Our comment was that “It ain’t VIRTUAL memory if it isn’t all there” as opposed to virtual addressing.
Weird comment. What does that mean? On a PDP-11, all your virtual memory
was always there when the process was on the CPU, but it might not be
there at other times. Just as not all processes memory would be in
physical memory all the time, since that often would require more
physical memory than you had.
But you normally did not have demand paging, since that was not really
gaining you much on a PDP-11. On the other hand, overlays do the same
thing for you, but in userspace.
So you would claim that ATT Unix did not have virtual memory because it
didn't do demand paging?
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
Fake news knocks on the doors of Unixland: there's absolutely
no truth to the claim that the rm command was written by
Robert Morris. Rm was there from the beginning, when only
two people wrote Unix code--Thompson and Ritchie. In fact,
it would have been on PDP8 Unix, which Morris never used.
Doug
On 4/22/18, Clem cole <clemc(a)ccc.com> wrote:
>
> BTW if you want to be correct about dates - the DEC released the Vax in 76
> not 78 ( I personally used to program Vax serial #1 at CMU under VMS 1.0
> before I was at UCB which is what Dan had asked).
As I remember it, DEC announced the VAX in 1976 or 1977, and first
official customer ship didn't happen until 1978. Holy Cross had one
of the hardware beta machines in 1977. It ran a beta version of VMS
(version X0.5 initially). I ported a bunch of programs to the VAX,
including the PDP-10 version of Adventure.
-Paul W.
On 2018-04-24 01:30, Grant Taylor <gtaylor(a)tnetconsulting.net> wrote:
> On 04/23/2018 04:15 PM, Warner Losh wrote:
>> It's weird. These days lower LBAs perform better on spinning drives.
>> We're seeing about 1.5x better performance on the first 30% of a drive
>> than on the last 30%, at least for read speeds for video streaming....
> I think manufacturers have switched things around on us. I'm used to
> higher LBA numbers being on the outside of the disk. But I've seen
> anecdotal indicators that the opposite is now true.
That must have been somewhere in the middle of history in that case. Old
(proper) drives had/have track 0 at the outer edge. The disk loaded the
heads after spin up, and that was at the outer edge, and then you just
locked on to track 0, which should be near.
Heads had to be retracted for the disk pack to be replaced.
But this whole optimization for swap based on transfer speeds makes no
sense to me. The dominating factor in spinning rust is seek times, and
not transfer speed. If you place the swap at one end of the disk, it
won't matter much that transfers will be faster, as seek times will on
average be much longer, and that will eat up any transfer gain ten times
over before even thinking. (Unless all your disk ever does is swapping,
at which time the heads can stay around the swapping area all the time.)
Which is also why the file system for RSX (ODS-1) placed the index file
(equivalent of the inode table) at the middle of the disk by default.
Not sure if Unix did that optimization, but I would hope so. (Never dug
into that part of the code.)
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
Computer pioneer Niklaus Wirth was born on this day in 1934; he basically
designed ALGOL, one of the most influential languages ever, with just
about every programming language in use today tracing its roots to it.
His name is pronounced "vurt" but he would accept "worth", and he joked
that you could call him by name or by value (you need to know ALGOL to
understand).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
>Date: Mon, 23 Apr 2018 13:51:07 -0400
>From: Clem Cole <clemc(a)ccc.com>
>To: Ron Natalie <ron(a)ronnatalie.com>
>Cc: Tim Bradshaw <tfb(a)tfeb.org>, TUHS main list <tuhs(a)minnie.tuhs.org>
>Subject: Re: [TUHS] /dev/drum
>Message-ID:
> <CAC20D2PEzAayjfaQN+->kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q(a)mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
... some stuff removed ...
>Exactly... For instance an RK04 was less that 5K blocks (4620 or some
>such - I've forgotten the actually amount). The disk was mkfs'ed to the
>first 4K and the left over was give to the swap system. By the time of
>4.X, the RP06 was 'partitioned' into 'rings' (some overlapping). The 'a'.
>partition was root, the 'b' was swap and one fo the others was the rest.
>Later the 'c' was a short form for copying the entire disk.
Wondered why, but I guess now I know that's the reason Digital UNIX on
alpha used the same disk layout. From a AlphaServer DS10 running
DU4.0g, output "disklabel -r rz16a"
# /dev/rrz16a:
type: SCSI
disk: BB009222
label:
flags:
bytes/sector: 512
sectors/track: 168
tracks/cylinder: 20
sectors/cylinder: 3360
cylinders: 5273
sectors/unit: 17773524
rpm: 7200
interleave: 1
trackskew: 66
cylinderskew: 83
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0
8 partitions:
# size offset fstype [fsize bsize cpg] #
NOTE: values not exact
a: 524288 0 AdvFS # (Cyl. 0 - 156*)
b: 1572864 524288 swap # (Cyl. 156*- 624*)
c: 17773524 0 unused 0 0 # (Cyl. 0 - 5289*)
d: 0 0 unused 0 0 # (Cyl. 0 - -1)
e: 0 0 unused 0 0 # (Cyl. 0 - -1)
f: 0 0 unused 0 0 # (Cyl. 0 - -1)
g: 4194304 2097152 AdvFS # (Cyl. 624*- 1872*)
h: 11482068 6291456 AdvFS # (Cyl. 1872*- 5289*)
> From: "Ron Natalie"
> I'm pretty sure that swapping in V6 took place to a major/minor number
> configured at kernel build time.
Yup, in c.c, along with the block/character device switches (which converted
major device numbers to routines).
> You could create a dev node for the swap device, but it wasn't used for
> the actual swapping.
Yes.
> We actually dedicated a full 1024 block RF11 fixed head to the system in
> the early days
Speaking of fixed-head disks, one of the Bell systems used (IIRC) an RS04
fixed-head disk for the root. DEC apparently only used that disk for swapping
in their OS's... So the DEC diagnsotics felt free to scribble on the disk.
So, Field Circus comes in to work on the machine... Ooops!
Noel
> From: Clem Cole
> To be honest, I really don't remember - but I know we used letters for
> the different partitions on the 11/70 before BSD showed up.
In V6 (and probably before that, too), it was numbers:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man4/rp.4
So on my machine which had 2 x 50MB CalChomps, with a Diva controller, which
we had to split up into two partition each (below), they were dv00, dv01, dv10
and dv11. Letters for the partitions made it easier...
> The reason for the partition originally was (and it must have been 6th
> edition when I first saw it), DEC finally made a disk large enough that
> number of blocks overflowed a 16 bit integer. So splitting the disk
> into smaller partitions allowed the original seek(2) to work without
> overflow.
No, in V6 filesystems, block numbers (in inodes, etc - also the file system
size in the superblock) were only 16 bits, so a 50MB disk (100K blocks) had to
be split up into partitions to use it all. True of the RP03/04 in V6 too (see
the man page above).
Noel
Ingo wrote:
> i have been working hard to reduce the number of options of low usefulness
Ah, soothing classical Unix Musik, so rare in the cacophonous Linux era.
Doug
Ray Tomlinson, computer pioneer, was born on this day in 1941. He is
credited with inventing this weird thing called "email" on the ARPAnet, in
particular the "@" sign to designate a remote host (although some jerk --
his name is not important -- is claiming that he was first).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Clem Cole:
On the other hand, we still 'dump core' and use the core files for
debugging. So, while the term 'drum' lost its meaning, 'core file' - might
be considered 'quaint' by todays hacker, it still has meaning.
====
Just as we still speak of dialling and hanging up the phone,
electing Presidents, and other actions long since made obsolete
by changes of technology and culture.
Norman Wilson
Toronto ON
> From: Warner Losh
> Drum memory stopped being a new thing in the early 70's.
Mid 60's. Fixed-head disks replaced them - same basic concept, same amount of
bits, less physical volume. Those lasted until the late 70's - early PDP-11
Unixes have drivers for the RF11 and RS0x fixed-head disks.
The 'fire-hose' drum on the GE 645 Multics was the last one I've heard
of. Amusing story about it here:
http://www.multicians.org/low-bottle-pressure.html
Although reading it, it may not have been (physically) a drum.
> There never was a drum device, at least a commercial, non-lab
> experiment, for the VAXen. They all swapped to spinning disks by then.
s/spinning/non-fixed-head/.
Noel
Does anyone know if UToronto's MRS database system (from about 1979) has
survived? It was described in:
Robert Hudyma, John Kornatowski, Ivor Ladd. MRS: A microcomputer
database management system. Proceedings of the 1981 ACM SIGSMALL
symposium on Small systems and SIGMOD workshop on Small database
systems, pp 174-180.
Apparently it was distributed to over 50 unix sites. This is the
software which became the MISTRESS and later EMPRESS products.
De
The recent Empress and earlier PC[67]300 conversations have churned my
failing memory to catch up on the CTIX versions I ran throughout the
1980s.
I (sort of) remember 5.x and 6.x as being the releases we faced. The 5.x
ones were derived from SVR1 IIRC. When 6.x arrived, SVR2+ was the order
of the day, but I don't recall much or anything of SVR3 creeping in.
Certainly no RFS or the like. And Convergent wasn't shy about letting
bits of Berkeley code sneak in when that made sense.
I think the UUCP code got a significant update between 5 and 6. Didn't
the 5.x uucico have the "window > 3 == core dump" bug? By 6.x I recall it
grew 'G' protocol (at least).
Any ex-Convergent hacks on the list who can fill in the blanks?
--lyndon
We lost software engineer Dick Hustvedt on this day in 2008, following
severe injuries in a vehicle accident. He contributed much to RSX-11 and
VMS, including the infamous "microfortnight" and the SD730 Fixed Head
Solar Horologue. An obituary of him can be found at
http://software.intel.com/en-us/blogs/2008/04/23/dick-hustvedt-the-consumma…
(and it's worth reading).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
We lost Robert Taylor, computer scientist and Internet pioneer, on this
day in 2017. Amongst other things, he helped invent the mouse, pioneered
computer communications leading up to ARPAnet, developed the computer
science lab at Xerox...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Today I reached a minor milestone with my 'Venix restoration project' that
I talked about months ago. I ran a Venix 86 binary (sync) to successful
completion on my FreeBSD/amd64 box (though none of the code should be too
FreeBSD specific).
So, I hacked https://github.com/tkchia/reenigne.git to remove the DOS
loader and emulator and to add a Venix system call loader and emulator, or
at least the start of one. I've also added FP instruction parsing, but it's
100% wrong (it just parses the instructions and does nothing else to decode
or implement them). With this, I'm able to load OMAGIC binaries from the
extant venix 86 distributions and run them. The only one that runs
successfully is sync() since I've not yet implemented argument passing or
any of the other 58 system calls :). NMAGIC should be pretty quick after
this.
This is but a step on the road to getting the Venix compiler running so I
can see how much of the system I can recreate from the v7 and other sources
that are on TUHS.
Not sure who, if anybody, cares about this stuff. I thought people here
might be interested. I've pushed the results to
https://github.com/bsdimp/venix if you care. This program is in the
tools/86sim directory. There's also a doc directory where I document the
Venix 86 ABI, as well as doing a very deep-dive into a disassembled
/bin/sync to discover what I can from it (turns out, it's quite a lot).
So, I thought I'd share this here. Don't know if anybody else is
interested, but you never know until you tell people about stuff...
Warner
I was sure that I'd read a paper on the legal history of Unix. So I did a
Google search for it, and found a link to the PDF. The linked PDF was on
the TUHS website :-)
http://wiki.tuhs.org/lib/exe/fetch.php?media=publications:theses:gmp_thesis…
I'd better do a backup of my brain, as I've got a few flakey DRAM chips.
Cheers, Warren
