From: Jonathan de Boyne Pollard on
>
>>
>> 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
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

"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
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

"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