[email protected] (John Gilmore) writes: > <begin extract> > one of the things that I did have lots of problems with was supporting > position independent code (mentioned in the tss/360 wiki article) > ...constantly having to hack code to make in position independent > </end extract> > > Is 'position independent' code the same as location-independent code? > Presumably not, since location-dependent code, which gives trouble > when modifications are made elsewhere in its containing routine, is > something that I have tried to avoid for a good many years now. (I > recall with no fondness a 60-year-old pseudo-random number generator > that was location-dependent.)
re: http://www.garlic.com/~lynn/2014d.html#25 [OT ] Mainframe memories I've used position & location independence somewhat interchangeably. In my use for cp67/cms page mapped filesystem and in tss/360 use ... the executable image on disk could be directly mapped to any address in memory w/o any further alterations or changes. traditional os/360 image had "relocatable address constants" ... originally the executable image would be loaded into some arbitrary address in real storage ... and then the loading process would cycle through the list of relocatable address constants ... appropriately adjusting them for the loaded address/location. http://en.wikipedia.org/wiki/OS/360_Object_File_Format in tss/360, position/location independance met that the executable image on disk could be mapped to arbitrary address in virtual memory w/o having to change/adjust antyhing (there was no such thing as os/360 relocatable address constants). going from 360/67 to 370 virtual memory ... it was limited to only 24bit virtual addressing ... which could be configured as 256 64kbyte segments. in my paged mapped implementation ... http://www.garlic.com/~lynn/submain.html#mmap it was possible to map executable images (or any file system object) as one or more shared segments (single copy appearing simultaneously in multiple different virtual address spaces). with position independence, any address space could have any combination of shared objects at any arbitrary virtual address. in the location/position dependent subset implementation (characteristic of os/360 & relocatable address constant paradigm), each shared object effectively had to have a unique virtual address across the whole system (in effect it had to be reloaded at some address, and all the relocatable address constants "fixed" for that address, and that image written back to disk). this became extremely problamatical in a large system when the total aggregate of all possible shared objects exceeded 16mbytes. in the location/position independent implementation any single virtual address space could have any possible combination of shared objects up to a total of 16mbytes. in the location/position dependent subject, a virtual address space couldn't have shared objects that had been predefined at the same address (even if there was still large amount of remaining space at other locations in the virtual address space) http://www.garlic.com/~lynn/submain.html#adcon re: http://www.garlic.com/~lynn/2014d.html#16 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#22 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#23 [OT ] Mainframe memorie http://www.garlic.com/~lynn/2014d.html#26 [OT ] Mainframe memorie -- 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
