l...@garlic.com (Anne & Lynn Wheeler) writes: > 360/67 support 4kbyte pages and 1mbyte segments ... but it also > supported 24bit and 32bit virtual addressing modes (aka 16mbyte and > 4gbyte virtual address spaces). > > 370 support 2kbyte and 4kbyte pages and 64kbyte and 1mbyte segments > ... but only 16mbyte virtual address sapce. > > cp67 was modified to provide 370 virtual address spaces ... supporting > all the 370 option combinations ... it had "shadow tables" that emulated > the various 370 options (using the rules defined for the hardware TLB, > table lookaside buffer) ... which mapped the 370 virtual machine virtual > address spaces (2k&4k pages, 64k&1m segments) to the 370 virtual machine > space. This was in regular use on 360/67 a year before the first 370 > hardware engineering machine was operational with hardware virtual > memory support. > > basically vm370 adopted the cp67 shadow table approach ... but mapped to > 370 hardware tables instead of mapped to 360/67 hardware tables.
re: http://www.garlic.com/~lynn/2013c.html#13 I do not understand S0C6 on CDSG 2kbyte versus 4kbyte virtual pages were trade-off between efficiency between being able to pack a program into small real storage against efficiency of I/O transfer of larger blocks ... even when all the larger page might not be required. as real storage got larger and disk i/o became more & more a bottleneck the trade-off of 2kbyte pages shifted more and more to larger page sizes. in the wake of FS failure http://www.garlic.com/~lynn/submain.html#futuresys there was resumed efforts to get products back into 370 pipeline. I got roped into helping with one of these with ECPS (vm370 microcode assist) for 138/148 (follow-on to 135/145 ... faster processor, larger real storage as well as larger storage for microcode). Old post describing some of the ECPS effort in spring of 1975: http://www.garlic.com/~lynn/94.html#21 370 ECPS VM micrcode assist A combination of ECPS, VS1/VM370 handshaking, larger storage, etc resulting in VS1 running faster under vm370 than on bare real machine. Part of this was VS1/VM370 handshaking layed out the VS1 virtual address space in VM370 virtual machine address space of the same size ... so VS1 never directly did its own page .... i.e. all paging activities were done by VM370 4kbytes at a time (compared to the VS1 2kbytes at a time paging). The other issue was my page replacement algorithm in vm370 and my VM370 pathlength for doing paging operations were both significantly better than VS1 (or OS/VS2, SVS and MVS). As part of this, Endicott attempted to convince corporate that all 138 and 148 machines should be shipped with vm370 natively installed at the factory (short of like current generation with every machine with LPAR). However, this was in the period that POK was convincing corporate to kill off the vm370 product, shutdown the vm370 development group, move all the people to POK (other otherwise POK wouldn't be able to meet the MVS/XA ship schedule in the 80s). Endicott managed to obtain the VM370 product mission but had to reconstitute a VM370 development group from scratch (and weren't able to convince corporate that vm370 ship on every Endicott machine). In the case of OS/VS2 (both SVS and MVS) I couldn't do anything about their enormous pathlengths for paging & page i/o ... but I did try (unsuccesfully) to get them to do much better page replacement algorithms ... pointing out some very bad decisions that they were making as part of their original effort. There was one scenario with incorrect decision in page replacement living on well into MVS release cycle ... when somebody finally fixed it ... and got an award for fixing it. They then called to see if they could do something similar/award for vm370. I pointed out that I had never done it wrong since the original changes I made as undergradudate in the 60s to cp67 ... and in fact tried to prevent the OS/VS2 crowd from originally doing it wrong. misc. past posts mentioning paging & page replacement algorithms http://www.garlic.com/~lynn/subtopic.html#wsclock -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
