[comp.arch] Physical >= Virtual

don@gp.govt.nz (Don Stokes, GPO) (11/24/89)

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. 

ggw@wolves.uucp (Gregory G. Woodbury) (11/26/89)

In article <593@gp.govt.nz> don@gp.govt.nz (Don Stokes, GPO) writes:
>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.
>
>Of course that is 2GB *virtual*.  
>
>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.

	As sometimes occurs, both are correct.  The VAX architecture features
a split instruction and data space, and there are page tables for each of the
spaces.  1 GB of instruction space + 1 GB of data space = 2 GB of virtual
address space.
	This is not to mention the other bit (of course) that indicates that
you are accessing the 2 GB of virtual space reserved for the system, where
all the real interesting stuff is -- the real memory, the i/o devices and
the page tables themselves.
-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu  ggw@ac.duke.edu  ggw%wolves@ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>