Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!lll-lcc!styx!twg-ap!amdahl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP
Newsgroups: comp.arch
Subject: Re: 64 Vs 32
Message-ID: <720@mcgill-vision.UUCP>
Date: Wed, 1-Apr-87 02:30:40 EST
Article-I.D.: mcgill-v.720
Posted: Wed Apr  1 02:30:40 1987
Date-Received: Thu, 9-Apr-87 00:10:35 EST
References: <3810013@nucsrl.UUCP> <985@rpics.RPI.EDU> <1310@ucbcad.berkeley.edu>
Organization: McGill University, Montreal
Lines: 28

In article <1310@ucbcad.berkeley.edu>, faustus@ucbcad.berkeley.edu (Wayne A. Christopher) writes:
> I don't know if this is the right question to ask....  [...] the most
> one process could address is 4G of virtual memory.  In the case of
> the VAX, 1/4 of this is "regular" data and text space, 1/4 is stack
> space, and the other half is system space.

Not quite.  1/4 is text+data (0x00000000-0x3fffffff, or P0 space), 1/4
is stack and assorted system trash (on UNIX, the u struct and the
process kernel stack live here) (0x40000000-0x7fffffff, or P1 space),
1/4 is normally used by the kernel (0x80000000-0xbfffffff, or system
space), and 1/4 is reserved (0xc0000000-0xffffffff).  Only the low half
(P0 and P1) is per-process; the other half (system and reserved) is
common to all processes.  The virtual memory hardware (firmware)
enforces this much of a distinction (though it doesn't enforce things
like system space being inaccessible to user-mode code; that's up to
the system software to set up).

> I certainly haven't been running into the 1G limit too often lately.

Neither have I :-).  But then, I haven't been doing image processing or
complicated spectrum analysis....

					der Mouse

Smart mailers: mouse@mcgill-vision.uucp
USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu