The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > actually such speculation dates back three decades to the introduction > of cross-memory instructions and dual-address space mode on 3033 re: http://www.garlic.com/~lynn/2008c.html#29 New Opcdoes http://www.garlic.com/~lynn/2008c.html#32 New Opcdoes http://www.garlic.com/~lynn/2008c.html#33 New Opcdoes part of the speculation was that the cross-memory/dual-address space instructions used more STOs (segment table origins) simultaneously ... and the 3033 had inherited its TLB (and STO-associative) implementation from 168. The additional concurrent STO use activity was putting pressure on TLB-miss and therefor performance. one the other hand, large 168 & 3033 installation were facing enormous pressure on amount of application addressable space ... aka pasts posts about pointer passing paradigm from real memory heritage dictated the SVS and subsequent MVS implementation with the kernel appearing in the application address space. The MVS design included moving (non-kernel) subsystems into their own address space ... dictating the common segment implementation (supporting squirreling away data for pointer passing APIs). Larger installations were having to constantly grow the common segment ... with 24bit addressing (16mbyte), kernel taking up 8mbytes ... and the common segment growing from 4mbytes to 5mbytes (and more) ... was only leave 3-4mbytes (or less) for applications (even tho there was a virtual address space per application). the future system distraction had redirected a lot of effort into non-370 activity http://www.garlic.com/~lynn/subtopic.html#futuresys when future system was killed, there was mad rush to get stuff back into the 370 product pipeline. 370-xa was going to take 7-8 yrs (with 31-bit addressing, access registers, program call & return, etc). the stop-gap was 3033 ... which was 168 wiring/logic remapped to faster chip technology. The increasing machine capacity was adding more applications, tending to grow the common segment and putting massive pressure on available (virtual) memory for applications. There was speculation that 3033 cross-memory and dual-address space hardware changes was purely to create incompatibilities for the clone processor vendors ... however there was more than enuf other justification, even if the clone vendors hadn't existed at all (intermediate step on the way to access registers) ... aka dual-address space instructions allowed subsystem to reach directly into the calling application's virtual address to direclty access values pointed to by the passed pointers (w/o requiring the common segment hack). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
