🚀 go-pugleaf

In article <6808@pt.cs.cmu.edu>, lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:
> My trusty VAX Architecture Handbook states that a process may have at
> most 2 GB of virtual memory.  This means that the VAX will have maxed
> out.  To go further would mean that the physical memory would be
> larger than a virtual space. IBM is already there!
> 
> That's happened to DEC before - with the PDP-11 and the DEC 20 both.
> I hope they, at least, remember how painful it was to all concerned.

I don't need my Architecture Handbook to say that 8-)  

Of course that is 2GB *virtual*.  The limits for user code don't change
with a change in physical memory, but the more memory, the less paging,
and the better the performance - which is the whole purpose of providing
lotsa core.  They used to build VAXes with 256KB of physical memory, and
they still addressed 2GB virtual.  If you want a bigger address space,
buy a Cray. 

But my VAX/VMS internals manual gives the page table entry's page frame 
number size as 21 bits = 2^21(pfn) * 512(page size) = 1GB.  Which means, 
under the current architecture, the machine maxes out at that point.  
But, that doesn't actually matter terribly, as the pfn database is the 
OS's problem, not user code - VMS could easily be modified to use a 
different pfn layout without breaking very much existing code.  Of course 
they could pull filthy tricks and include the owner access mode bits to 
the page number......

The guts - not a problem.  

Don Stokes  ZL2TNM  /  /                                 vuwcomp!windy!gpwd!don
Systems Programmer /GP/ Government Printing Office       PSI%0530147000028::DON
__________________/  /__Wellington, New Zealand__________don@gp.govt.nz________
Programming is built on teamwork; it allows you to blame somebody else.