[email protected] (Paul Gilmartin) writes: > Further, with UNIX shared memory and the older CSA and LPA > a single page, possibly executable, can be mapped into multiple > address spaces. It better be reentrant. > > The address ranges wouldn't need to be identical if the code > were location independent. This may have been a goal of the > S/360 designers, never exploited in OS/360 software.
os/360 relocation adcons became fixed when executable was loaded into storage before execution. tss/360 did implement location independent executable images (where same image could be mapped simultaneously into different virtual address spaces at different locations. when i did page-mapped filesystem for (cp67/)cms in the early 70s, I also implemented location independent support ... but CMS primarily used OS/360 assembler/compile/loader conventions (with relocatable adcons that got fixed at load time, rather than the tss/360 model) ... I frequently had to significantly massage os/360 "generated" code to make it location independent. I then ported the support to vm370/cms ... and a very small subset was included in vm370 release 3, w/o the paged map filesystem and the location independent support. past posts mentioning horrible contortions I sometimes had to resort to in order to have location independent code. http://www.garlic.com/~lynn/submain.html#adcon I would say that when I did the CMS page-mapped filesystem ... I avoided doing all the things that I saw tss/360 had done wrong (from performance stand point, it did do the location independent correctly). Possibly one of the reasons that the full page-mapped stuff wasn't included in vm370 release 3 was because the (failed) FS effort had pretty much adopted the tss/360 model ... and "page-mapped" got such a bad reputation with the FS failure ... some past posts http://www.garlic.com/~lynn/submain.html#futuresys even tho I could show my cms page-mapped filesystem had 3-4 times the throughput of the native cms filesystem (both original and EDF). some past filesystem http://www.garlic.com/~lynn/submain.html#mmap other trivia, something similar also shows up at the time of decision to migrate all 370 to virtual memory ... recent post mentioning major motivation was the horrible MVT storage management. http://www.garlic.com/~lynn/2016h.html#98 A Christmassy PL/I tale Simpson (from HASP), rather than going to gburg as part of HASP/JES group ... went to Hawthorne and did "RASP" ... a MFT2 based implementation supporting an (os/360 oriented) paged-map filesystem ... which showed some of the advantages for (os/360 based) virtual memory systems. When it wasn't picked up, he left IBM and joined a clone processor maker ... where he re-implemented RASP from scratch. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
