Moving buttembler programs above the line 506

... some of those details ...

TSS-360 was the "official" system for 360-67 ... while cp67 was done at cambridge science center

at one point i believe there were something like 1200 people working on tss-360 at a time when there were 12 people working on cp67.

initially, 370 was announced w-o virtual memory (you got "real storage" dos, mft, mvt continuing to run on 370s).

in preperation for virtual memory announcement for 370, cp67 morphed into vm-370, dos to dos-vs, mft to vs1, and mft to SVS.

the initial prototype for SVS was mvt with a little glue to setup a single virtual address space ... and "CCWTRANS" borrowed from CP67 to do the CCW chain scanning, pin virtual pages in real memory, create the "shadow" CCWs, translate virtual CCW addresses to real addresses, etc. basically you had MVT running in a single 16mbyte virtual address. Morphing from SVS to MVS gave each application their own 16mbyte virtual address space (although the kernel and some subsystems continued to reside in every virtual address space).

previous post

part of the issue was that non-virtual memory 370 was just an interim step on the way to "FS" (furutre system)

FS was going to be as bigger a departure from 360 than 360 had been a departure from eariler computers. supposedly one of the major justification was FS ... was the compebreastion from clone controllers

when i was an undergraduate, i got to work on a project that reversed engineered the ibm channel interface and built a channel interface board that went into a minicomputer ... which was programmed to emulate an ibm controller. four of us got written up being responsible for spawning clone controllers

some folklore is that amdahl left to build clone processors in a disagreement over the FS direction. in the early 70s, Amdahl gave a talk in mit auditorium where he was asked about what arguments did he use in business case to justify funding. he answered that there was already at least $100b invested in 360 customer application software, and even if ibm were to immediately walk away from 360s (veiled referenced to FS), there would still be customer demand for "360" processors at least thru the end of the century.

more folklore is that some of the FS refugees went to rochester and implemented FS as s-38.

Also that 801-RISC project

was at least partially motivated to do the exact opposite hardware implementation from FS (extremely simple rather than extremely complex).

virtual memory could be activated on 135 & 145 with just changing the microcode ... however significant hardware had to be added to 155s and 165s to get virtual memory capability.

the 370 "red book" (architecture manual done in cms script, superset of principle of operations, depending on which cms script option set ... you either printed the full architecture manual ... or just the principle of operations subset sections) had several more features in 370 virtual memory than what was announced.

one of the additional features was (shared) segment protection. The morphing of CMS from cp67 to vm370 was going to make use of the 370 shared segment protection. however, coming down to the wire, the 165 engineers at one point said that if they only had to do a subset of the 370 virtual memory architecture ... they could get it out six months earlier (or to do the full 370 virtual memory implementation would delay 165 virtual memory support by six months ... which would delay the 370 virtual memory announcement for all processors by six months).

POK operating system people (SVS) said they had no need for any of the additional 370 features and to go ahead with the subset ... in order to get virtual memory out six months earlier. this then hit CMS ability to do (shared) segment protection ... and resulted in doing a real hack that played with the storage protect keys.

this is similar ... but different to the POK operating system people saying that they didn't need any atomic syncronization primitive other than test&set for SMP support ... which drove the science center to come up with the application description use for compare&swap in multi-threaded environments ... recent reference

vm microcode buttist was added to 158 & 168 processors ... basically control register six was loaded and various privilege instructions would be executed (in the hardware) ... in problem state mode ... but following virtual machine rules (saving interrupt into cp kernel and software simulation). over the years this expanded into pr-sm and lpars.

this worked with various virtual guests machines ... but didn't work with CMS ... because of the hack playing with the storage protection keys ... wasn't understood by the microcode buttists. A new scheme was invented for vm370 release 3 which eliminated the game playing with the storage protection keys for CMS shared segment protection ... allowing use of the vm microcode buttist on 158 & 168 processors for cms environments. it used a gimick that didn't protect shared segments ... but at task switch time would scall all pages in shared segments for modification (and if found, invalidate the page and force a refresh of unmodified page to be paged in from disk). The issue was that the overhead of scanning of (at most) 16 virtual pages (at every task switch) was less than the performance improvement using the hardware microcode buttists (in cms intensive environments).

the problem was that for release 3 ... they also picked up a small subset of my virtual memory management changes (called DCSS):

which, at a minimum, doubled the number of shared pages that had to be scanned at every task switch. It turned out that the overhead scanning (at least) twice as many pages in shared segments ... was more than the performance savings from using the vm microcode buttist ... i.e. by the time the change shipped to allow cms intensive environments to use microcode buttist ... the performance trade-off for the change was no longer valid.

--