Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp
Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!well!ptsfa!l5!gnu
From: gnu@l5.uucp (John Gilmore)
Newsgroups: net.arch
Subject: Re: Why Virtual Memory
Message-ID: <242@l5.uucp>
Date: Mon, 4-Nov-85 16:24:22 EST
Article-I.D.: l5.242
Posted: Mon Nov  4 16:24:22 1985
Date-Received: Fri, 8-Nov-85 04:19:12 EST
References: <480@seismo.CSS.GOV>, <384@unc.unc.UUCP> <6086@utzoo.UUCP> <2184@amdahl.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 34

In article <2184@amdahl.UUCP>, mat@amdahl.UUCP (Mike Taylor) writes:
> (In Sharp APL under DOS...)                      In order that a damaged
> workspace could not cause the interpreter to run amok and damage other
> workspaces, storage protect keys were used.  Storage protect keys are
> a S/370 architectural feature which matches a nibble in the PSW to
> a nibble associated with each 2K block of storage. To "run" a workspace,
> the APL interpreter used the SSK instruction to set the workspaces storage
> to a "working" protect key, and then ran under that protect key.
> They then changed to a technique which used all available protect keys
> to minimize the number of actual SSKs, but finally solved the problem
> by going to virtual memory.

My information is that they ran their production system with all
workspaces in the same protect key, so they never had to do SSK, since
their Amdahl mainframes were so slow at that particular instruction,
and since the production code was sufficiently bug-free that it could
be trusted not to damage other users' workspaces.  (Recall that in the
previous system, such a bug would have caused a protection fault, which
is reported to the console.  They knew exactly how many of these a week
would occur, typically zero.)  The move to virtual memory (DOS->MVS)
was definitely NOT done to speed up SSK instructions; the system ran
much slower after the change.

I don't see how changing a page table entry on an Amdahl can be any
less expensive than changing a storage protect key (since they alter
the protection of the same region of storage) but maybe they thought
"nobody uses SSK much, let's not put much work into it".  The same
thing happend with the 360 "ex" (execute) instruction, which is pretty
heavily used by APL.  This causes an instruction pipe flush since the
early pipe stages are not smart enough to notice that ex is like a
1-instruction branch.  (Amdahls DO optimize branches.)

So maybe the answer to "Why virtual memory" is "Because the hardware
designers optimized for it rather than other equally viable techniques".