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