The Pankian Metaphor 3099

ref:

the other part of the os real memory heritage was that applications and program data was buttumed to be loading at any arbitrary adddress in real memory along with the fact that code generation convention arbitrarily intermixed instructions and data and that there was extensive use of absolute address constants for all sorts of addressing operations.

for the program image on disk, this address constants (which could be liberally found through out the program image) were stored in relative displacement form ... with a "relocatable address constant" directory appended to the file.

after the loader had read the program completely into memory (in later years, virtual memory), the loader then had to read the relocatable address constant directory ... which gave the location in the program image of each one of the address constants ... and access each one, changing it from its relative location value to its absolute location value.

after that the loader could transfer control to the starting application address.

cp67-cms eventually borrowed many applications from the os-360 software base (buttemblers, compilers, and various other applications). cms having started from a virtual memory base where potentially every application could be loaded at the same (virtual) address ... added a new program image type called "MODULE". After the program loader had pulled everything into memory and did is address constant swizzling bit ... it was possible to write to disk an application program image file ... which then could be subsequently reloaded ... w-o the loader having to run through the image fixing up all the address constants in the program image.

i was somewhat able to take advantage of this when i did paged mapped filesystem for cp67-cms

however, i also wanted to support library program images that could be simulataneously (read-only) shared simultaneously in multiple different virtual address spaces). the issue with library images is that they are loaded at arbitrary different addresss (in a virtual address space) in conjunction with arbitrary different applications. one possibility is to buttign each possible library program a fixed, unique virtual address. however, with only 16mbytes of virtual address space to work with, there quickly were more possible library programs than there were available unique virtual addressess. any specific application, run at any specific moment, would require more than 16mbytes of library programs .... but across all possible applications and all possible library programs ... there were more than could fit in 16mbytes. this is somewhat akin to the mvs "common segment" scenario mentioned here (even tho it had multiple different virtual address spaces)

and the single virtual address space of s-38 going with 48bit virtual address (which later morphed into as-400)

various other systems designed from the ground up for virtual memory (like tss-360, multics), defined program image formats were location dependent things like address constants were managed separately from basic program image. while cms had been define as virtual memory operation ... it borrowed a lot of applications, buttemblers, compilers, coding conventions, etc ... from (real memory) os-360.

in doing the memory mapped filesystem work for cms ... attempting to create some number of (address) location independent program images that could be directly memory mapped as (read-only) shared objects at arbitrarily different address in different virtual address spaces ... i spent a lot of time fiddling with address constants in various applications. numerous past postings describing the address constant fiddling activity

--