Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.unix.misc > #79

Re: which one came first

From Anne & Lynn Wheeler <lynn@garlic.com>
Newsgroups comp.unix.misc, alt.folklore.computers
Subject Re: which one came first
Date 2012-04-23 21:49 -0400
Organization Wheeler&Wheeler
Message-ID <m362cp292c.fsf@garlic.com> (permalink)
References <jn4965$sfh$1@reader1.panix.com> <ylfkty0as0qf.fsf@dd-b.net> <barmar-EB9943.17563823042012@news.eternal-september.org> <m3aa2212s4.fsf@garlic.com>

Cross-posted to 2 groups.

Show all headers | View raw


re:
http://www.garlic.com/~lynn/2012f.html#28 which one came first

360/67 had 1mbyte segments, 256 4k pages ... and 24bit and 32bit virtual
addressing modes (16 1mbyte and 4096 1mbyte)

370 just had 24bit virtual addressing ... but had 1mbyte and 64kbyte
virtual segment sizes and 4kbyte and 2kbyte virtual page size options.

the original 370 virtual memory specification had a bunch of additional
options ... included r/o shared segment bit in segment table entries.
370s were announced and shipped before virtual memory feature was
announced ... virtual memory later had to be retrofitted. most machines
implemented the full 370 virtual memory specification ...  and in the
cp67/cms to vm370/cms transition, cms was reorganized to make use of the
64kbyte "read-only" (protected) shared segments (16 4kbyte shared
pages). problem arose retrofitting the full 370 virtual memory
specification to 370/165 ... and in order to get back six months in
schedule ... it was decided to drop several virtual memory features
... included r/o shared segment protection (370 models that had already
implemented the full set of features had to go back and remove the
dropped features).

vm370/cms was then stuck with how to have protected shared segments when
the hardware support had been dropped.

360 (and 370) had 2k "storage-protect" keys ... left over from 360
real-storage protection ... 4bit key for every 2kbyte of storage and PSW
field ... if PSW field matched the storage key ... store operations were
allowed (psw key of zero turned off store protect).

vm370/cms retreated to real hack to emulate segment protect ... cms
virtual machine with any shared "segments" always had its psw key set to
"15" and all non-shared storage set to "15" ... and all 2k areas in
"shared segment" were set to zero (preventing all stores in shared
pages).

w/o memory-mapped filesystem ... cp67 & vm370 had a real hack ... special
area in paging system ... appropriate privileges could execute "savesys"
command that wrote image of virtual pages to the special area. The
machine "IPL" command was allowed to be a name of the special area (as
alternative to device address) ... which would map virtual memory to the
saved named area. "named systems" have special configuration specifying
the pages saved/restored ... and the segments designated as "shared"
(& protected)

i could elimiante all that in cp67 with memory-mapped filesystem ...
and then moved the support to vm370 base. One of the big problems I
constantly fought was os/360 "relocatable address constants".  CMS
borrowed compilers and applications from os/360 ... as well as many
conventions. os/360 relocatable address constants were application on
disk ... the application is fully read into (emulated real) storage
... and all relocatable address constants were swizzled to correspond
with the address where application was loaded. 

memory-mapped filesystem should allow executiable applications mapped to
any available addres w/o having to thread way through lots of the image
... swizzling all the address constants (making them absolute). Swizzled
"absolute" addresses (after loading) also results in problems with
sharing exact same image in different virtual address spaces.

tss/360 addressed the design by having the address fields in application
images as relative to some virtual address space specific field. For me,
I was constantly battling the os/360 relocatable address constant
convention used by cms ... misc. past posts
http://www.garlic.com/~lynn/submain.html#adcon

-- 
virtualization experience starting Jan1968, online at home since Mar1970

Back to comp.unix.misc | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

which one came first jgk@panix.com (Joe keane) - 2012-04-23 19:05 +0000
  Re: which one came first David Dyer-Bennet <dd-b@dd-b.net> - 2012-04-23 14:32 -0500
    Re: which one came first Barry Margolin <barmar@alum.mit.edu> - 2012-04-23 17:56 -0400
      Re: which one came first Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-23 18:50 -0400
        Re: which one came first Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-23 21:49 -0400
  Re: which one came first scott@slp53.sl.home (Scott Lurndal) - 2012-04-23 21:44 +0000
    Re: which one came first jeffj@panix.com (Jeff Jonas) - 2012-05-15 02:41 -0400
      Re: which one came first sarr.blumson@alum.dartmouth.org - 2012-05-15 13:45 +0000
        Re: which one came first Barry Margolin <barmar@alum.mit.edu> - 2012-05-15 10:14 -0400
        Re: which one came first Ahem A Rivet's Shot <steveo@eircom.net> - 2012-05-15 15:29 +0100
          Re: which one came first "Charles Richmond" <numerist@aquaporin4.com> - 2012-05-17 09:28 -0500
            Re: which one came first Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2012-05-17 15:24 +0000
              Re: vfork and stuff which one came first John Levine <johnl@iecc.com> - 2012-05-17 22:35 +0000
            Re: which one came first Ahem A Rivet's Shot <steveo@eircom.net> - 2012-05-17 16:39 +0100
  Re: which one came first Peter Flass <Peter_Flass@Yahoo.com> - 2012-04-23 21:07 -0400
    Re: which one came first Peter Flass <Peter_Flass@Yahoo.com> - 2012-04-23 21:12 -0400

csiph-web