Shmuel Metz , Seymour J. wrote: > No. The B5000, dating back to 1959, is an example of a system without > paging that supported virtual memory larger than physical memory. OS/2 > 1.x is another, more recent, example.
the semantics of the statement didn't preclude systems w/o paging but with defined virtual memory that was larger than physical memory. the semantics of the statement was merely observing that there had been "some" systems that had defined virtual memory that wasn't larger than physical memory ... and discussed an example. it gave an example of boeing having modified a os/360 mvt release 13 to have virtual memory cobbled on the side running on 360/67 (supporting virtual memory hardware). the modifications didn't include support for paging, had the amount of defined virtual memory the same as physical memory ... and the use was to manage contiguous storage fragmentation for long running (2250 graphics) applications. the semantics of the statement also weren't intended to apply to the architecture amount of virtual addressing vis-a-vis the amount of real addressing. the 360/67 support (normal) 360 24-bit real addressing, 24-bit virtual addressing (as well as 32-bit, not 31-bit, virtual addressing). However 360/67 had 1mbyte max. real storage (360/67 two-processor smp supported 2mbyte combined real storage ... 1mbyte from each processor). the semantics of the statement were intended to mearly point out that there had been some systems configured such that the amount of configured virtual storage and the amount of real storage were identical ... but doing so, could still serve some useful purpose. a different variation of this done for vm/vs1 "handshaking". VS1 had a single virtual memory table (similar to vs2/svs). For vm/vs1 handshaking ... you might define a 4mbyte VS1 virtual machine ... VS1 would then define a (single) 4mbyte virtual address space ... effectively having a one-for-one mapping between the VS1 virtual address space and its perceived "real" (virtual machine) address space. When handshaking was enabled, VM could present "virtual" page faults to the VS1 virtual machine ... VM would perform the actual page (replacement) operation ... but it would allow VS1 supervisor and opportunity to perform task switch to a different task. VM would also present a psuedo I/O interrupt to VS1 when the paging operation had finished. This eliminated double paging overhead (various performance penalties having both the virtual machine and VM doing paging operations). In addition, the VM paging implementation was more efficient the VS1 implementation. I had drastically reduced the paging pathlength when I had rewritten it for cp67 (in the 60s when i was an undergraduate). There was also a significant reduction in paging pathlength as well as the accuracy of the page replacement algorith that I released in the resource manager for vm370. misc. collected posts about scheduling features in the resource manager http://www.garlic.com/~lynn/subtopic.html#fairshare misc. collected posts about paging and page replacement algorithms ... some of which also appeared in the resource manager release http://www.garlic.com/~lynn/subtopic.html#wsclock ---------------------------------------------------------------------- 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
