Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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.
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 | Next — Previous in thread | Next in thread | Find similar
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