Processes' memory
|
Prev: GPS resolutio (was Re: SYSENTER/SYSEXIT_vs._SYSCALL/SYSRET)
Next: F r e e C I S C O C e r t i f i c a t i o n s
From: Jonathan de Boyne Pollard on 21 Jan 2010 11:55 > >> >> This is very platform specific. No law even says a UNIX system has to >> support virtual memory. >> > Yes to the "platform specific" part, but could a non-VM system > implement fork()? (Beyond `errno=ENOMEM; return -1;', that is?) > In addition to M. Schwartz' answer of swapping instead of paging there is another possibility. Consider systems where pointers are not merely unadorned address words. It's quite possible for pointers to incorporate some form of "process ID" such that even though all processes share a single address space, when dereferenced pointers that differ in "process ID" access different parts of that address space. Of course, implementing fork() necessitates having a tag bit that marks each portion of memory that is being used as a pointer, so that the fork() implementation can find and adjust all of the pointers in the child process.
From: "Andy "Krazy" Glew" on 25 Jan 2010 09:16 Jonathan de Boyne Pollard wrote: >> >>> >>> This is very platform specific. No law even says a UNIX system has to >>> support virtual memory. >>> >> Yes to the "platform specific" part, but could a non-VM system >> implement fork()? (Beyond `errno=ENOMEM; return -1;', that is?) >> > In addition to M. Schwartz' answer of swapping instead of paging there > is another possibility. Consider systems where pointers are not merely > unadorned address words. It's quite possible for pointers to > incorporate some form of "process ID" such that even though all > processes share a single address space, when dereferenced pointers that > differ in "process ID" access different parts of that address space. Of > course, implementing fork() necessitates having a tag bit that marks > each portion of memory that is being used as a pointer, so that the > fork() implementation can find and adjust all of the pointers in the > child process. I've used UNIX systems that swapped the entire process in/out to disk. Less extreme, systems that supported address mapping, but not pagefaults.
From: Anne & Lynn Wheeler on 25 Jan 2010 10:34 "Andy \"Krazy\" Glew" <ag-news(a)patten-glew.net> writes: > I've used UNIX systems that swapped the entire process in/out to disk. > > Less extreme, systems that supported address mapping, but not pagefaults. in 60s, 360/65 was real addresses only ... 360/67 was basically 360/65 with hardware (associative array) added for doing virtual address translation. officially intended for tss/360 (which had lots of development and delivery problems). the science center did virtual machine cp67 for 360/67 ... and was installed on lots of the (supposedly tss/360) 360/67 machines (lots of univ. had bought 360/67 to run tss/360). os/360 was standard operating system product for running on 360s (w/o virtual memory). Boeing Huntsville had installed multiprocessor 360/67 for running os/360 doing a lot of (long-running) 2250 graphics display (lots of cadam-like design apps). os/360 had big problem with 1) applications required contiguous addressing and 2) storage fragmentation with long-running applications. Boeing modified os/360 MVT13 to support virtual address mapping (no page faults, no paging) to fake contiguous addressing ... as work-around to os/360 storage fragmentation problem. some of the things involved in the way tss/360 implemented its "one-level-store" implemented poorly ... resulted in severe performance degradation ... and lack of customer uptake. A lot of the one-level-store concepts from tss/360 ... were then involved in the failed future system effort ... lots of past posts http://www.garlic.com/~lynn/submain.html#futuresys folklore is that some number from future system retreated to rochester to do s/38 ... which as/400 is follow-on. in the early 80s, I tried to get a project to re-implement CMS (from cp67 and then vm370) in portable (higher-level) programming language so that it could run on 801/risc Iliad chips ... in addition to 370. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Anne & Lynn Wheeler on 25 Jan 2010 10:47 Anne & Lynn Wheeler <lynn(a)garlic.com> writes: > some of the things involved in the way tss/360 implemented its > "one-level-store" ... resulted in severe performance degradation > ... and lack of customer uptake. re: http://www.garlic.com/~lynn/20010c.html#4 Processes' memory as undergraduate at the univ. in 60s, I got to worked on os/360, cp67, and little on tss/360. later when I did a paged-mapped filesystem for cms ... I used a lot about what not to do from what I had experienced with tss/360. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Mike on 26 Jan 2010 22:48
"Anne & Lynn Wheeler" <lynn(a)garlic.com> wrote in message news:m3r5pe19n1.fsf(a)garlic.com... | | folklore is that some number from future system retreated to rochester | to do s/38 ... which as/400 is follow-on. | | in the early 80s, I tried to get a project to re-implement CMS (from | cp67 and then vm370) in portable (higher-level) programming language so | that it could run on 801/risc Iliad chips ... in addition to 370. | I have often wonder how modern systems would have evolved in an alternate universe where IBM did not fund MicroSoft and OS/2 but instead chose to implement Presentation Manager to provide a GUI on top of VM/CMS and compete in the micro and workstation arena with a 370 instruction set chip. In 1984 IBM had a PC/370 but decided it would eat mainframe revenue and limited software licenses to machines connected to mainframes thus killing their attraction. Your suggestion of a portable version of CMS is an intriguing alternate especially if combined with a portable GUI. Just think, an industrial strength GUI on 370, 801, and S/38 and on PC's to compete with Windows 3.1. Mike |