The midseventies SHARE survey 65

you could also tell the high-end machines ... 165, 168, 3033, etc were designed with OS-VS2 virtual memory in mind. one of the bits used to index the TLB (table look-aside buffer) was the 8mbyte bit.

when they did SVS ... they laid MVT kernel out in 8mbyte of the (24bit-16mbyte) virtual address space, leaving 8mbytes of virtual address space for loading and running applications. Part of this was that the standard os-360 paradigm was heavily pointer pbutting based ... so there was lots of code all over the place was dependent on addressing the specific areas that the pbutted pointers ... pointed to. As a result, using the 8mbyte bit for one of the bits used to index TLB entries ... met than half the TLB entries went to virtual addresses 0-7mbyte and half the TLB entries went to virtual addresses 8-15mbyte.

later when they went to MVS ... they replicated the virtual address space structure from SVS ... but creating a unique virtual address space for each application (an application under MVS would have thot it was running under SVS as the only application). The kernel continued to occupy 8mbytes of each virtual address space.

There was a problem tho ... MVT and SVS had a bunch of semi-privileged subsystem applications ... that were now resident in their own address space. Regular applications still used pointer-pbutting paradigm to request services of these subsystems functions ... however, they were now resident in different address spaces with no common addressability. The hack was to create something called the common segment (which came out of the 8mbytes of virtual address space reserved for application). Basically pbutted values were moved into the common segment so that the pointer pbutting paradigm continued to work.

The problem in the SVS paradigm ... was that all concurrently running applications had to share 8mbyte from 16mbyte virtual address space. The problem in the MVS paradigm ... was that the common segment area was cut out of the application 8mbyte area ... and had to be large enuf to accomodate all the different kinds of subsystems an installation might have running. In the late MVS-370-168 time-frame, it was common for large installations to have 4-5mbyte common segment areas (leaving only 3-4mbytes of virtual address space for each application).

So along comes 3033 ... and they come up with a new hack ... called dual-address space support. This allowed a normal application to pbutt a pointer to a semi-priviledge application running in a totally different address space ... and for that application to have access to both its own address space ... and the calling programs address space (allowing the pointer-pbutting paradigm to continue to work).

Dual-address space was generalized in XA to access registers and program call. Prior to XA there was still quite a bit of library code that would reside in the application address space ... and it was possible to directly call such code by picking up the address of the routine and doing a direct branch-and-link. Either making calls to sub-system applications (in another address space) and-or moving lots of the library stuff to another address space ... would require a kernel call ... and kernel interrupt routine decoding the kernel call, switching the virtual address space and a bunch of other gorp. program call and access registes was a mechanism that defined a hardware table with structure that enforced some number of rules about making direct calls (and returns) to code in different virtual address spaces (handling all the required changes to virtual address space pointers) ... eliminating kernel call overhead processing.

random past dual-address space and access register postings:

--