dave@sdeggo.UUCP (09/13/87)
In article <692@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: (there was more up here about GNU being better than Minix for software development) > Are you implying that Version 7 wasn't suitable for research or commercial > development? Remember... UNIX didn't start out as BSD 4.3 either. Thank > the gods (Thompson & Ritchie). BSD would never have run on the machines > available in the early and mid seventies, just as GNU won't run on the > personal computers available today. It's not a case of wasn't; it was. It isn't today (at least not a PDP-11 based version), and neither is Minix in its present, IBM PC form. Minix is an impressive effort, and I give Dr. Tanenbaum his due, but I would hate to have to develop a large software package (has anyone ported "hack" yet?) under it. It's kind of like all the people who have taken Pascal (designed as a _teaching_ language, to be hand compiled by an instructor!) and wanted to try and develop real software in it. It's possible, but it ain't pleasant. BSD 4.3 would run just fine on an 80386 and it does run just fine on 68000's and 68020, so there is no reason that GNU wouldn't. "Personal computers available today" are available based on those chips, and that is where the market is heading. Wtih some work, (as Peter pointed out in his article, but I already threw away that part :-( ) Minix could be changed to be BSD compatible. The first task, though is to port it to a 68000 (with a good memory manager) or an 80386 and get around the 64K task size limit. The rest could be added in slowly. This might beat GNU out the door, but I'm not sure of the status of the GNU project. Why are so many people so anxious to beat on it? Someone's doing you a favor and all you can do is bitch about how "it's not here, it's too big, it doesn't do what I want it to do, my machine can't run it..."? Cripes, don't look a gift horse in the mouth. Especially one that nobody's really seen yet. -- David L. Smith {sdcsvax!sdamos,ihnp4!jack!man, hp-sdd!crash}!sdeggo!dave sdeggo!dave@sdamos.ucsd.edu "How can you tell when our network president is lying? His lips move."
ast@cs.vu.nl (Andy Tanenbaum) (09/14/87)
In article <87@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >With some work, ... Minix could be changed to be BSD compatible. The first >task, though is to port it to a 68000 (with a good memory manager) or an >80386 and get around the 64K task size limit. The rest could be added in >slowly. As has been pointed out already, MINIX has already been ported to the 68000, albeit without an MMU. That (Atari) version is now in beta testing. The Atari version does not have a 64K limit. Actually, I think that if anyone is going to do that much work, a much better idea is to modify MINIX to make if conform to the POSIX standard, which is the UNIX of the future. Here is a suggestion/request in that direction. Will someone who is familiar with POSIX draw up a list of POSIX system calls, noting for each one whether 1. it is identical to the corresponding MINIX call 2. it is different from the corresponding MINIX call 3. it is not present in MINIX at all Similarly, for each program and library routine in POSIX, a similar list would be useful. That way people who want to get together and make MINIX more "real world", could at least have a specific list of what needs to be done, and the target would be something that will eventually be an International Standard, rather than 4.3, which is not likely to survive once an International Standard has been established for UNIX systems. Andy Tanenbaum (ast@cs.vu.nl)
preston@felix.UUCP (Preston Bannister) (09/14/87)
In article <87@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >It's kind of like all the people who have taken Pascal ... >and wanted to try and develop real software in it. It's possible, but it >ain't pleasant. Please, no language R-wars. I've used C, Modula-2, Pascal and Lisp quite a lot at different times. None of them is universally preferable to the other. And yes, I _have_ developed "real" software in Pascal. >BSD 4.3 would run just fine on an 80386 and it does run just fine on 68000's >and 68020, so there is no reason that GNU wouldn't. "Personal computers >available today" are available based on those chips, and that is where the >market is heading. Close but not quite. The 68000, 68010 and 68020 cannot support demand paged virtual memory without an MMU. The (original) 68000 has a basic flaw that makes implementing virtual memory ugly even _with_ an MMU. The only easily availible (i.e. low cost) machine with a suitable support for demand paged virtual memory is the 80386-based PC family. The next closest candidate is the Mac II, which will have a reasonable MMU sometime soon (when Motorola gets it's new MMU chip out the door). That leaves out the vast majority of personal computers. >With some work, ... >Minix could be changed to be BSD compatible. I would think that the best long-term goal would be to make Minix as close to Posnix compatible as possible. >The first >task, though is to port it to a 68000 (with a good memory manager) or an >80386 and get around the 64K task size limit. The rest could be added in >slowly. The add something constructive to this discussion... :-) I think what we should _really_ be thinking about is how to make Minix match the availible machines more closely. One thing about Unix that has always bugged me is the fork() primitive. The fork primitive _assumes_ that you can make an _exact_ copy of a running process. That's rather difficult (expensive, ugly...) on a machine that doesn't support the right flavor of virtual memory. It also ties the process abstraction and the virtual address space abstraction together (i.e. you can't have more than one process in the same address space). Most uses of fork() are immediately followed by an exec() call. Why else do you think the BSD people came up with vfork()? A direct "start program in a seperate process" call would accomplish the same effect and would be easily implementable on machines without hardware support for (the right flavor of) virtual memory. I'd rather see primitives like "start process in same address space", "start process in new address space", and "start program in new address space". (Perhaps this could be orthogonalized by combining primitives for program-loading, process creation, and address space creation). I suspect with a little thought, the primitives could be implemented _efficiently_ on a much wider range of machines. -- Preston L. Bannister USENET : ucbvax!trwrb!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister
rlk@think.COM (Robert Krawitz) (09/16/87)
In article <7320@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes: ]In article <87@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: ]>BSD 4.3 would run just fine on an 80386 and it does run just fine on 68000's ]>and 68020, so there is no reason that GNU wouldn't. "Personal computers ]>available today" are available based on those chips, and that is where the ]>market is heading. [...386 boxen and Mac II w/68851] ]That leaves out the vast majority of personal computers. These days. How about t[gettimeofday()+2yrs]? That, after all, is what the FSF is heading for. ]>With some work, ]... ]>Minix could be changed to be BSD compatible. ] ]I would think that the best long-term goal would be to make Minix as ]close to Posnix compatible as possible. Minix was designed as a teaching system, not as a production system. It would take lots of hacking to hammer it into shape. For that matter, so would GNU, I suppose, but it's starting from a premise that strikes me as more amenable to a production machine. ]I think what we should _really_ be thinking about is how to make Minix ]match the availible machines more closely. One thing about Unix that ]has always bugged me is the fork() primitive. The fork primitive ]_assumes_ that you can make an _exact_ copy of a running process. ]That's rather difficult (expensive, ugly...) on a machine that doesn't ]support the right flavor of virtual memory. It also ties the process ]abstraction and the virtual address space abstraction together (i.e. ]you can't have more than one process in the same address space). Hmm...seems to me that you could implement fork() on an 8086, if you used a small memory model and programs cooperated (didn't play with the segment registers). The PDP11 didn't have virtual memory either, if my memory serves me. To run multiple processes concurrently you need memory management, but not necessarily virtual memory. To fork, you need some way of creating distinct address spaces. You certainly don't need virtual memory. Since Minix runs on an 8086 just fine, and that's the weakest processor that anyone has any interest in running multiprocess things on, I don't see why this is a problem. ]Most uses of fork() are immediately followed by an exec() call. Why ^^^^ ]else do you think the BSD people came up with vfork()? For these cases. A direct "start ]program in a seperate process" call would accomplish the same effect ]and would be easily implementable on machines without hardware support ]for (the right flavor of) virtual memory. That already exists in BSD and probably in SysV, but as a library call implemented in terms of fork() (or vfork()) and exec(). In fact, Kernighan & Pike give an example of a rewritten system() useful for special purposes (it's been a while since I read it, so forgive me for no page or context reference). ]I'd rather see primitives like "start process in same address space", ]"start process in new address space", and "start program in new ]address space". (Perhaps this could be orthogonalized by combining ]primitives for program-loading, process creation, and address space ]creation). I suspect with a little thought, the primitives could be ]implemented _efficiently_ on a much wider range of machines. Vfork in BSD is implemented reasonably efficiently (compared to fork, at least), and it's hard to see why it couldn't be implemented correctly on a non-VM machine. Remember that when you do a vfork, the child process shares the address space of the parent (indeed, the parent goes to sleep until the child exits or forks). This may be what you're looking for. But remember, fork() is useful by itself in many circumstances, such as daemons that handle more than one input or output channel (sendmail, inetd, etc.). Personally, I'd rather see machines that have facilities powerful enough to run big, powerful software like GNU and emacs. I don't care for software that's been held back because of {IBM,Microsoft,Intel} brain damage. Just because a large blue company and clones sell more computers than anyone else doesn't mean that it's the way to go. I'm more interested in 68020/68030, 80386 or 80486 whenever that happens because the life cycle will probably be a lot longer. Robert^Z
chips@usfvax2.UUCP (Chip Salzenberg) (09/19/87)
In article <7320@felix.UUCP>, preston@felix.UUCP writes: > > Most uses of fork() are immediately followed by an exec() call. Why > else do you think the BSD people came up with vfork()? A direct "start > program in a seperate process" call would accomplish the same effect > and would be easily implementable on machines without hardware support > for (the right flavor of) virtual memory. There is one thing about UNIX fork()-exec() that you've overlooked -- after the fork(), the child process can set up the environment of the soon-to-be-exec'ed process by modifying its own environment. (Can you say `pipes, I/O redirection and current directory'? I knew you could.) > I'd rather see primitives like "start process in same address space", > "start process in new address space", and "start program in new > address space". > -- > Preston L. Bannister Under OS-9, there is no UNIX-style fork(); there is a combined fork()-exec(). Granted that it's efficient on 6809 and 680x0 even without an MMU, it's still a royal pain. The parent process must dup() its file descriptors, open the child's, fork(), close the child's, and restore its own. And those dup'ed file descriptors are still open on the child! Blech. I'd like `new process, same address space', but for spawning another program, E{NIX semanitics are elegant and useful. -- Chip Salzenberg UUCP: "uunet!ateng!chip" or "chips@usfvax2.UUCP" A.T. Engineering, Tampa Fidonet: 137/42 CIS: 73717,366 "Use the Source, Luke!" My opinions do not necessarily agree with anything.
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (09/21/87)
In article <8490@think.UUCP> rlk@THINK.COM writes: >.... The PDP11 didn't have virtual memory either, >if my memory serves me. .... At the risk of re-opening an old debate, the PDP-11 \does/ have virtual memory. It's just that, for various technical reasons, the original Unix implementation for it chose to use swapping instead of paging as its virtual memory technique. Yes, it's a nit, but the PDP-11 is a fine machine, and deserves to be remembered correctly. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM
preston@felix.UUCP (09/21/87)
In article <838@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes: >There is one thing about UNIX fork()-exec() that you've overlooked -- >after the fork(), the child process can set up the environment of the >soon-to-be-exec'ed process by modifying its own environment. >(Can you say `pipes, I/O redirection and current directory'? I knew you could.) The point I was trying to make was that the fork() is typically followed by an exec() call and that the full semantics of fork() are not needed in those cases. What I should have said :-) was that the code executed between the fork() and exec() call typically does not need the full semantics of fork(). An extreme example would be to imagine, say, a program that is using a large amount of memory that wants to run some other program with the output into a pipe that it would read. The sequence would be something like: - open pipe - fork - assign one end of pipe for child's standard output - exec - (parent process now can read output of child from pipe) The fork call is going to be awefully expensive, as a copy of the entire data space of the parent will be made. The code between the fork() and exec() really doesn't need that copy, as all it does is make a small modification to the context of the child process. We need to factor out the management of process contexts (the set of open files, mapping of signals, etc.) from the management of the address/data space. What I'm looking for is a good set of primitives. From my point of view, fork() and exec() are not really primitives, as they represent a number of different operations. Fork() can be factored to: - create new process context - copy parent process context to new context - create new address space - copy parent's data to new address space Exec() can be factored to: - delete address/data space - create new address/data space - load code from given file - begin execution of code from file (Did I miss something?) Current typical uses of fork()/exec() could be replaced by: - create new process context - copy parent process context to new context (typical code to reassign files, signals, etc) - create new address/data space - load code from given file - begin execution of code from file -- Preston L. Bannister USENET : ucbvax!trwrb!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister
henry@utzoo.UUCP (Henry Spencer) (09/22/87)
> Most uses of fork() are immediately followed by an exec() call. Why > else do you think the BSD people came up with vfork()? A direct "start > program in a seperate process" call would accomplish the same effect > and would be easily implementable on machines without hardware support > for (the right flavor of) virtual memory. Be careful. Most uses of fork() are *not* immediately followed by an exec() call; the two are usually separated by some manipulation of things like file descriptors and signals. A combined fork-exec is definitely possible, since the OS/9 people did it, but it's not as simple as it sounds at first. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
chips@usfvax2.UUCP (09/24/87)
In article <7672@felix.UUCP>, preston@felix.UUCP (Preston Bannister) writes: } In article <838@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes: } } >There is one thing about UNIX fork()-exec() that you've overlooked -- } >after the fork(), the child process can set up the environment of the } >soon-to-be-exec'ed process by modifying its own environment. } >(Can you say `pipes, I/O redirection and current directory'? } >I knew you could.) } } What I should have said :-) was that the } code executed between the fork() and exec() call typically does not } need the full semantics of fork(). } } An extreme example would be to imagine, say, a program that is using a } large amount of memory that wants to run some other program with the } output into a pipe that it would read. } } We need to factor out the management of process contexts (the set of } open files, mapping of signals, etc.) from the management of the } address/data space. } } -- } Preston L. Bannister I agree that fork() does much more than is necessary in some cases. For example, I use an editor that forks twice as preparation for running an area of text through a filter; that really _is_ expensive, since our editor is quite large. (No, not emassive :-}; the Rand editor `E'.) -- Chip Salzenberg UUCP: "uunet!ateng!chip" or "chips@usfvax2.UUCP" A.T. Engineering, Tampa Fidonet: 137/42 CIS: 73717,366 "Use the Source, Luke!" My opinions do not necessarily agree with anything.
root@hobbes.UUCP (09/25/87)
> Most uses of fork() are immediately followed by an exec() call.
When this came up last spring, someone (gwyn?) grep'd thru all the Unix
source and found a grand total of TWO places where fork() was immediately
followed by exec()! All the others had dup()s, close()s, and setuid()s, etc
stuck in between. In the future, please try to ground your "facts" in
something solid before making sweeping statements like that...
John
--
John Plocher uwvax!geowhiz!uwspan!plocher plocher%uwspan.UUCP@uwvax.CS.WISC.EDUpeter@sugar.UUCP (Peter da Silva) (09/25/87)
In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: > In article <8490@think.UUCP> rlk@THINK.COM writes: > >.... The PDP11 didn't have virtual memory either, > >if my memory serves me. .... > > At the risk of re-opening an old debate, the PDP-11 \does/ have virtual > memory. It's just that, for various technical reasons, the original Unix > implementation for it chose to use swapping instead of paging as its virtual > memory technique. And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), probably because it didn't in fact have the capability of supporting VM. Why do you think DEC developed the Virtual Address Extension (VAX) in the first place? > Yes, it's a nit, but the PDP-11 is a fine machine, and deserves to be > remembered correctly. As a great little non-virtual system. Nothing wromng with that. Sometimes virtual memory means virtual performance, as a good many PDP-11 fans have pointed out. You can run way more users on and get way better real-time response from a PDP 11/70 than any VAX you care to name. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (09/26/87)
Just one question. What are you doing between the time you deleted the address and data space and leaded the new one? Running out of /dev/null? Yes, fork isn't a machine primitive. Very few UNIX system calls are. Read, for example, "should" be: Read required block from file. Copy data from block to buffer. If any more blocks need to be read, repeat. Update current pointer. A number of operating systems expect you to do all this stuff. I'll stick with UNIX and read/write/fork/exec, thanks. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (09/26/87)
>In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: >> ... the PDP-11 \does/ have virtual >> memory. It's just that, for various technical reasons, the original Unix >> implementation for it chose to use swapping instead of paging as its virtual >> memory technique. In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), >probably because it didn't in fact have the capability of supporting VM. You don't give the criteria by which you make this rather bald claim, but I'll try to respond to it anyway. The test for virtual memory is whether the name space of the process is independent of the name space of the processor; that is, the memory seen by the process is the same, no matter where it is located in physical (real) memory. In other words, if the process can be moved to a new place in memory and is unaware that it has been moved, then the process memory is virtual, and the architecture supports virtual memory. The PDP-11 passes this test. If you are trying to say that the PDP-11 didn't permit a process to be run without all of its image mapped, that is indeed true of some processor models. (But not all models -- I've seen experimental versions of Unix on the PDP-11 that were demand paged.) But this isn't a requirement for virtual memory; it just makes alternative virtual memory schemes (like paging) more attractive. >Why do you think DEC developed the Virtual Address Extension (VAX) in the >first place? Yes, DEC did indeed extend the amount of virtual memory available, from a maximum of two 64k pieces to ~2G. I'll even agree that that's quite an extension -- over four orders of magnitude. But they extended the amount, not the concept. >..... Sometimes >virtual memory means virtual performance, as a good many PDP-11 fans have >pointed out. You can run way more users on and get way better real-time >response from a PDP 11/70 than any VAX you care to name. There's some truth in that. I suspect that it's more of a function of the increasing size of programs (and the disk cost to read them in) than a function of the virtual memory architecture (although it \is/ due to virtual memory that programs have been able to bloat so much). But that is currently being mooted elsewhere, so I won't get on that soap box here. BTW, I'm assuming that you meant "interactive" when you said "real-time," since in an actual hard-real-time environment, I would want my tasks running with the memory management turned off and in a soft-real-time environment, I would want my tasks locked down. In either case, the overhead for virtual memory would be similar and the faster processor would win. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM
mash@mips.UUCP (John Mashey) (09/26/87)
In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: >> At the risk of re-opening an old debate, the PDP-11 \does/ have virtual >> memory. It's just that, for various technical reasons, the original Unix >> implementation for it chose to use swapping instead of paging as its virtual >> memory technique. >And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), >probably because it didn't in fact have the capability of supporting VM. >Why do you think DEC developed the Virtual Address Extension (VAX) in the >first place? Greg was right in the first place. As a good example, somebody at Naval Postgraduate school did a thesis where they modified UNIX to run demand-paged on an 11/55, and did various performance measurements. they found the paged version was superior in only a small domain. I recall the thesis included an honest, but somewhat chagrined comment like "Thompson was right; simple wins in this case". Why should this be? The technical reasons Greg alludes to are simple: If programs are relatively small [64K I + 64K D max] and if pages are relatively large (compared to size) [8K], then programs are likely to touch every or almost every page very quickly. In this case, you get better disk performance, and have simpler, denser kernel data structures, by swapping instead of paging. I.e., if working set = size of program, you might as well swap. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/27/87)
In article <7672@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes: >The fork call is going to be awefully expensive, as a copy of the >entire data space of the parent will be made. It need not be; don't copy the pages until a attempt to modify them occurs.
peter@sugar.UUCP (Peter da Silva) (09/28/87)
In article <1755@ncr-sd.SanDiego.NCR.COM>, greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes: > In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), > >probably because it didn't in fact have the capability of supporting VM. > > You don't give the criteria by which you make this rather bald claim, but I'll > try to respond to it anyway. Virtual memory == ability for a task to run without its entire address space residing in primary memory, in a manner that is transparent to the task itself. If you allow the task to manage the "VM", then you're letting overlays in and anything with secondary memory qualifies. This implies that it should be able to recover from a page fault. Now, someone else has claimed that the PDP-11 in some incarnations was able to do this. Since they seem to know whereof they speak, I'll accept it. But I stand on my claim that PDP11 does nore imply VM. What you're talking about... > The test for virtual memory is whether the name space of the process is > independent of the name space of the processor; that is, the memory seen by > the process is the same, no matter where it is located in physical (real) > memory. Is mapped memory (at least that's what DEC calls it, and it's a reasonable description. Especially since we're talking about DEC processors. > BTW, I'm assuming that you meant "interactive" when you said "real-time," > since in an actual hard-real-time environment, I would want my tasks running > with the memory management turned off and in a soft-real-time environment, I > would want my tasks locked down. In either case, the overhead for virtual > memory would be similar and the faster processor would win. Yeh, yeh. For hard real-time I wouldn't want anything more complicated in the way of operating systems than a scheduler. Down here in Houston real-time generally refers to SCADA, which makes most people's "soft realtime" look like granite. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
ejbjr@ihlpg.ATT.COM (Branagan) (09/28/87)
> > >.... The PDP11 didn't have virtual memory either, > > >if my memory serves me. .... > > > > At the risk of re-opening an old debate, the PDP-11 \does/ have virtual > > memory. It's just that, for various technical reasons, the original Unix > > implementation for it chose to use swapping instead of paging as its virtual > > memory technique. > > And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), > probably because it didn't in fact have the capability of supporting VM. > Why do you think DEC developed the Virtual Address Extension (VAX) in the > first place? Virtual memory != Support for demand paging The PDP-11 (later models only) does have virtual memory (i.e. supports a translation from logical to physical address). This was necessary to support more than 64K of physical memory on a machine only capable of addressing 64K - sort of backwards from the typical situation of using virtual memory to support processes which use more memory than physically available on the machine (or to the process). The PDP-11 does not have support for paging (i.e. does not generate convienient hardware interupts allowing a page to be brought into memory). Actually the problem here is that it is difficult to figure out how much of the instruction that faulted has executed already, and completing execution of the instruction which generated the fault (I've seen this done by interpreting the instruction in software, but it is very slow and gross). It looks like the designers made an attempt to add paging capabilities, but it was very difficult without major design and microcode changes (which lead to the VAX 11/780). SUMMARY: The PDP-11 (many models) does support virtual memory, though not for the same purposes as most machines. The PDP-11 has very poor support for paging, but it is theoretically (not practically) possible. -- ----------------- Ed Branagan ihnp4!ihlpg!ejbjr (312) 369-7408 (work)
henry@utzoo.UUCP (Henry Spencer) (09/29/87)
> The fork call is going to be awefully expensive, as a copy of the > entire data space of the parent will be made... Nonsense, not on a sensibly implemented system (4BSD as shipped from Berkeley does not count, although in fairness I should say that this one is not entirely their fault -- hardware bugs got in their way). It just has to *look* like a copy is made. Any half-decent virtual-memory system will do this with copy-on-write, so the bulk of the data never gets copied and the fork is cheap. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
ron@topaz.rutgers.edu (Ron Natalie) (09/29/87)
Actually, the PDP-11 has a perfectly good interrupt for bringing in pages. UNIX uses it to know when to grow the stack. The problem is that there are only eight (or 16 segments) to memory, so paging doesn't get you a whole lot. In addition, the shell, does user mode page faults to know when to grow its heap. -Ron
tim@ism780c.UUCP (Tim Smith) (09/30/87)
In article <840@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes:
< For example, I use an editor that forks twice as preparation for running
< an area of text through a filter; that really _is_ expensive, since our editor
< is quite large. (No, not emassive :-}; the Rand editor `E'.)
Forking does not have to be expensive for large programs. Fork should
just increase the reference counts on the text pages and data pages, and
change all data pages to be read-only. Only copy pages that get a write
fault.
--
Tim Smith, Knowledgian {sdcrdcf,uunet}!ism780c!tim
tim@ism780c.isc.com
"Oh I wish I were Matthew Wiener, That is who I truly want to be,
'Cause if I were Matthew Wiener, Tim Maroney would send flames to me"kent@tifsie.UUCP (Russell Kent) (09/30/87)
in article <6476@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) says: > Xref: tifsil comp.arch:729 comp.unix.wizards:1184 comp.os.minix:492 > > In article <7672@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes: >>The fork call is going to be awefully expensive, as a copy of the >>entire data space of the parent will be made. > > It need not be; don't copy the pages until a attempt to modify them occurs. Unfortunately, the machines that MINIX currently runs on do not have the memory management hardware to support the copy-on-write interrupt (ala DEC VAX processors). Nice try though :-) -- Russell Kent Phone: +1 214 995 3501 Texas Instruments - MS 3635 Net mail: P.O. Box 655012 ...!{ihnp4,uiucdcs}!convex!smu!tifsie!kent Dallas, TX 75265 ...!ut-sally!im4u!ti-csl!tifsie!kent
elg@usl (Eric Lee Green) (10/02/87)
>>In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: >>> ... the PDP-11 \does/ have virtual >>> memory. It's just that, for various technical reasons, the original Unix >>> implementation for it chose to use swapping instead of paging as its virtual >>> memory technique. I recently purchased the Bach book. The history he gives indicates that the probable reason Unix originally used swapping instead of paging, is because the early models of the PDP-11 that they originally implemented Unix on, did not support paging. In any event, you COULD run more programs than you had physical memory for, so I'd say that's virtual memory. -- Eric Green elg@usl.CSNET from BEYOND nowhere: {ihnp4,cbosgd}!killer!elg, P.O. Box 92191, Lafayette, LA 70509 {akgua,killer}!usl!elg "there's someone in my head, but it's not me..."
jfh@killer.UUCP (10/03/87)
In article <819@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: > > In article <8490@think.UUCP> rlk@THINK.COM writes: > > >.... The PDP11 didn't have virtual memory either, > > >if my memory serves me. .... > > > > At the risk of re-opening an old debate, the PDP-11 \does/ have virtual > > memory. It's just that, for various technical reasons, the original Unix > > implementation for it chose to use swapping instead of paging as its virtual > > memory technique. > > And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), > probably because it didn't in fact have the capability of supporting VM. > Why do you think DEC developed the Virtual Address Extension (VAX) in the > first place? > > > Yes, it's a nit, but the PDP-11 is a fine machine, and deserves to be > > remembered correctly. > > As a great little non-virtual system. Nothing wromng with that. Sometimes > virtual memory means virtual performance, as a good many PDP-11 fans have > pointed out. You can run way more users on and get way better real-time response > from a PDP 11/70 than any VAX you care to name. > -- > -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter > -- 'U` Have you hugged your wolf today? > -- Disclaimer: These aren't mere opinions... these are *values*. No, the registers and micro-code were present in _certain_ PDP-11's to handle virtual memory. I believe that certain micro-Vaxen _didn't_ actually have enough support to handle virtual memory as well as, say, a PDP-11/70. All that is required to support virtual memory is the ability to generate a CPU trap/fault on a reference to a non-existence/non-resident page of memory, and then figure out how to restart the intruction so that it completes as if the page were resident. Might sound a bit simple, but for all it's greatness, the 68000 and 808[86] can't handle virtual memory because in the general case, an instruction can not be restarted. The PDP-11's of the larger type (44/45/70/73/(34?)) could support virtual memory if the memory management hardware had been installed. When a non-resident segment (8 8KB segments for instruction and 8 more for data, except the 34, which didn't support separted I&D) was referenced, a trap was generated and the address of the instruction and PSW were stacked. The operating system then needed to simulate the rest of the instruction, if the failing cycle was a write. In the case of a read, you could make the segment valid (load the MMU's and what not) if no registers had been modified during the instruction, or attempt to simulate the instruction. Whew! Needless to say, I'd much rather swap than go through that mess. Anyway, Unix on 11's did do some neat things. I seem to recall that a trap on a write into a deeper stack address caused the system to backup that instruction and expand the stack. This is the suggested use for the direction bit in the MMU, according to my old '45 manual. If I remember from the days of wierd gone by, we had a C compiler that on entry to a function generated a jump past the jsr pc,cret which was a jump back to the instruction after the first jump. I suppose this `feature' could have been used to demand page text in, had anyone bothered. Anyhow, go read a _modern_ (or even old, like 11/45) manual and you too will become a believer... - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
guy%gorodish@Sun.COM (Guy Harris) (10/04/87)
> I recently purchased the Bach book. The history he gives indicates > that the probable reason Unix originally used swapping instead of > paging, is because the early models of the PDP-11 that they originally > implemented Unix on, did not support paging. I would be very surprised if this were the case. The PDP-11/20 that was the first PDP-11 on which UNIX was implemented (the first *machine* it was implemented on was a PDP-7), and it didn't have an MMU of any sort. The PDP-11/45, which was the second PDP-11 on which UNIX was implemented, did, however, have sufficient support for paging. See John Mashey's article, discussing paging UNIX on a PDP-11/55 (which was an 11/45 with bipolar memory hung off a fast memory bus). That article also cites what is probably the *real* reason UNIX didn't use paging; it added complexity and didn't buy you much at all. Some of the later PDP-11s that UNIX was ported to had an MMU but may or may not have been able to support demand paging; the 11/45's MMU included a register that, by recording changes made to registers by auto-increment and auto-decrement addressing modes, permitted the OS to back up an instruction that faulted in midstream. Other PDP-11s, however, did not; a backup routine that was sufficient to handle the case of faults taken by references past the end of the stack was provided for those machines. I don't think this routine was sufficient to handle *all* the cases of faults taken in midstream, at least not in a machine-independent manner. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
guy%gorodish@Sun.COM (Guy Harris) (10/04/87)
> I believe that certain micro-Vaxen _didn't_ actually have enough support to > handle virtual memory as well as, say, a PDP-11/70. Micro-*VAXen*? As far as I know, the MMU on all VAXes is the same. Did you mean micro-PDP-11s? > Might sound a bit simple, but for all it's greatness, the 68000 and 808[86] > can't handle virtual memory because in the general case, an instruction can > not be restarted. Well, there *are* ways of doing virtual memory without that kind of support; I think both Apollo and Masscomp did it with two 68000s, one of which was halted in mid-bus-cycle when it referenced an invalid page. The other one would then wake up and fetch the page, and let the original one continue its bus cycle when the page had been read in. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
ESC1332%ESOC.BITNET@wiscvm.wisc.edu (K.Keyte) (10/05/87)
Hey, hey.. wait a minute... ..all this talk about PDP-11s.. It's not _really)_ MINIX is it? Nice if you want to talk about it, but don't waste everyone's time since they only subscribed to this for MINIX info. PS: Sorry to post a non-MINIX message! Karl
Leisner.Henr@xerox.com (marty) (10/05/87)
RE: Unfortunately, the machines that MINIX currently runs on do not have the memory management hardware to support the copy-on-write interrupt (ala DEC VAX processors). Nice try though Not quite true. The 286 in protected mode will nicely generate restartable exceptions when attempting to write a read-only data segment. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:henr801c:xerox UUCP: martyl@rocksvax.uucp
zld@hpfcmp.HP.COM (Zemen Lebne-Dengel) (11/05/87)
/ hpfcmp:comp.os.minix / dave@sdeggo.UUCP (David L. Smith) / 4:38 pm Sep 12, 1987 / In article <692@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: (there was more up here about GNU being better than Minix for software development) > Are you implying that Version 7 wasn't suitable for research or commercial > development? Remember... UNIX didn't start out as BSD 4.3 either. Thank > the gods (Thompson & Ritchie). BSD would never have run on the machines > available in the early and mid seventies, just as GNU won't run on the > personal computers available today. It's not a case of wasn't; it was. It isn't today (at least not a PDP-11 based version), and neither is Minix in its present, IBM PC form. Minix is an impressive effort, and I give Dr. Tanenbaum his due, but I would hate to have to develop a large software package (has anyone ported "hack" yet?) under it. It's kind of like all the people who have taken Pascal (designed as a _teaching_ language, to be hand compiled by an instructor!) and wanted to try and develop real software in it. It's possible, but it ain't pleasant. BSD 4.3 would run just fine on an 80386 and it does run just fine on 68000's and 68020, so there is no reason that GNU wouldn't. "Personal computers available today" are available based on those chips, and that is where the market is heading. Wtih some work, (as Peter pointed out in his article, but I already threw away that part :-( ) Minix could be changed to be BSD compatible. The first task, though is to port it to a 68000 (with a good memory manager) or an 80386 and get around the 64K task size limit. The rest could be added in slowly. This might beat GNU out the door, but I'm not sure of the status of the GNU project. Why are so many people so anxious to beat on it? Someone's doing you a favor and all you can do is bitch about how "it's not here, it's too big, it doesn't do what I want it to do, my machine can't run it..."? Cripes, don't look a gift horse in the mouth. Especially one that nobody's really seen yet. -- David L. Smith {sdcsvax!sdamos,ihnp4!jack!man, hp-sdd!crash}!sdeggo!dave sdeggo!dave@sdamos.ucsd.edu "How can you tell when our network president is lying? His lips move." ----------