virtual memory 4469

precursor to as-400 was the s-38 ... which folklore has having been a bunch of future system people taking refuge in rochester after FS was end. reference to future system effort earlier in this thread.

misc. collected postings referencing FS. I didn't make myself particularly popular with the FS crowd at the time, drawing some parallel between their effort and a cult film that had been playing non-stop for several years down in central sq.

the transition of as-400 from cisc architecture to power-pc ... involved a lot of hangling during the 620 chip architecture days ... with rochester demanding a 65th bit to be added to the 64bit virtual addressing architecture (they eventually went their own way).

a few past posts mentioning 620, 630 and some of the other power-pc activities:

i've perodically mused that the migrations of as-400 to power-pc was somewhat fort knox reborn. circa 1980 there was an effort to migrate a large number of the internal microprocessors to 801 chips. one of these was to have been 370 4341 follow-on. I managed to contribute to getting that effort end ... as least so far as the 4381 was concerned. misc. collected posts mentioning 801, fort knox, romp, rios, somerset, power-pc, etc

for misc. other lore, the executive we had been reporting to when we started the ha-cmp product effort ... moved over to head up somerset ... when somerset was started (i.e. the apple, motorola, ibm, et all effort for power-pc).

the initial port of os-360 (real memory) mvt to 370 virtual memory was referred to as os-vs2 SVS (single virtual storage).

the original implementation was an mvt kernel laid out in a 16mbyte virtual memory (somewhat akin to mvt running in 16mbyte virtual machine) with virtual memory and page handler crafted onto the side ... and CCWTRANS borrowed from cp67.

the os-360 genre was real memory orientation with heavy dependancy on pointer pbutting in majority of the APIs ... being able to process any kind of service request required directly addressing parameter list pointed to by the pbutted pointer. this was, in part, big part of having address space for os-360 operation. The application paradigm involving I-O was largely dependent on direct transfer from-to application allocated storage. Application and library code would build I-O programs with the "real" address locations that were buttigned to the application. Transition to virtual memory environment, had the majority of application I-O involved pbutting address pointers to these application build I-O programs with "application" allocated storage addresses. In the real address world, the kernel would schedule some I-O permission restrictions and then transfer control directly to the application I-O program. In the transition to the virtual address space world ... all of these application I-O programs were now specifying virtual addresses ... not real addresses. CP67's kernel "CCWTRAN" handled the building of "shadow" I-O program copies ... fixing the required virtual pages in real storage and translating all of the supplied virtual address into real address for end of the "shadow" I-O programs.

recent post about CCWTRAN and shadow I-O programs

SVS evolved into MVS ... there was a separate address space for every application. However, because of the heavy pointer pbutting paradigm, the "MVS" kernel actually occupied 8mbytes of every application 16mbyte virtual address space. There was some additional hacks required. There were some number of things called subsystems that were part of most operational environments. They existed outside of the kernel (in their own virtual address space) ... but in the MVT & SVS worlds, other applications were in the habit of directly calling these subsystem functions using pointer pbutting paradigm ... which required the subsystems (which now were in separate address space) to directly access the calling application's parameters in the application's virtual address space.

The initial solution was something called a "COMMON" segment, a (again initially) 1mbyte area of every virtual address space where applications could stuff parameter values that they needed to be accessed by called subsystems, resident in other address spaces. Over time, as customer installations added a large variety of subsystems, it was unusual to find the COMMON segment taking up five megabytes. While these were MVS systems, with a unique 16mbyte virtual address space for every application, the kernel image was taking 8mbytes out of every virtual address space, and with a five megabyte COMMON area, that would leave a maximum of 3mbytes for application use (out of a 16mbyte virtual address space).

Dual-address space mode was introduced in the late 70s with 3033 processor (to start to alleviate this problem caused by the extensive use of pointer pbutting paradigm). This provided virtual address space modes ... a subsystem (in its own virtual address space) could be called with a pointer to parameters in the application address space. The subsystem had facilities that allowed it to "reach" into other virtual address spaces. A call to one of these subsystems still required pbutting through the kernel to swap virtual address space pointers ... and some other gorp.

recent mention of some connection between dual-address space and itanium

Along the way there was a desire to move more of the operating system library stuff that resided as part of the application code. So dual-address space was generalized to multiple address space and a new hardware facility was created called "program call". It was attempting to achieve the efficiency of branch-and-link instruction calling some library code with the structured protection mechanisms required to switch virtual address spaces by pbutting through priviledge kernel code. the privilege "program call" hardware table had a bunch of permission specification controls ... including which collection of virtual address space pointers could be moved into the various access registers. 31-bit virtual addressing was also introduced.

today there are all sorts of combinations of 24-bit virtual addressing, 31-bit virtual addressing, 64-bit virtual addressing ... as well as possibly several such virtual address spaces be able to be accessed concurrently.

3.8 Address spaces ... some overview including discussion about multiple virtual address spaces:

2.3.5 Access Registers ... discussion of access registers 1-15 can dissignate any address space

10.26 Program Call

10.27 Program Return

10.28 Program Transfer

--