"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Don't forget the single-address-space systems, of which the iSeries > (nee AS/400) is perhaps the most commercially successful example. Just > because process-per-address space is fashionable, doesn't mean it's > the only viable approach.
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 killed. reference to future system effort earlier in this thread. http://www.garlic.com/~lynn/2006i.html#32 virtual memory 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. http://www.garlic.com/~lynn/subtopic.html#futuresys 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: http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition) http://www.garlic.com/~lynn/2001i.html#24 Proper ISA lifespan? http://www.garlic.com/~lynn/2001i.html#28 Proper ISA lifespan? http://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan? http://www.garlic.com/~lynn/2004q.html#40 Tru64 and the DECSYSTEM 20 http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design http://www.garlic.com/~lynn/2005r.html#11 Intel strikes back with a parallel x86 design 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 killed ... as least so far as the 4381 was concerned. misc. collected posts mentioning 801, fort knox, romp, rios, somerset, power/pc, etc http://www.garlic.com/~lynn/subtopic.html#801 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). http://www.garlic.com/~lynn/subpubtopic.html#hacmp 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 passing in majority of the APIs ... being able to process any kind of service request required directly addressing parameter list pointed to by the passed 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 assigned to the application. Transition to virtual memory environment, had the majority of application I/O involved passing 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 execution of the "shadow" I/O programs. recent post about CCWTRAN and shadow I/O programs http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT SVS evolved into MVS ... there was a separate address space for every application. However, because of the heavy pointer passing 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 passing 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 passing 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 passing through the kernel to swap virtual address space pointers ... and some other gorp. recent mention of some connection between dual-address space and itanium http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed? http://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces 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 passing 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: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/3.8?SHELF=E Z2HW125&DT=19970613131822 2.3.5 Access Registers ... discussion of access registers 1-15 can dissignate any address space http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/2.3.5?SHELF =EZ2HW125&DT=19970613131822 10.26 Program Call http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.26?SHELF =EZ2HW125&DT=19970613131822 10.27 Program Return http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.27?SHELF =EZ2HW125&DT=19970613131822 10.28 Program Transfer http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.28?SHELF =EZ2HW125&DT=19970613131822 -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
