Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!uw-beaver!ubc-vision!alberta!bjorn
From: bjorn@alberta.UUCP
Newsgroups: comp.arch
Subject: Re: 64 Vs 32
Message-ID: <272@pembina.alberta.UUCP>
Date: Tue, 24-Mar-87 18:08:26 EST
Article-I.D.: pembina.272
Posted: Tue Mar 24 18:08:26 1987
Date-Received: Thu, 26-Mar-87 07:22:49 EST
References: <3810013@nucsrl.UUCP> <985@rpics.RPI.EDU> <2610@phri.UUCP>
Organization: U. of Alberta, Edmonton, AB
Lines: 40
Summary: Vax address space

In article <2610@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes:
> 	A question: I remember reading somewhere that the top 2 bits in a
> VAX address signify user/kernel and data/text segments, which really leaves
> you with "only" a 30-bit address space.  Is that a hardware feature or just
> the way VMS sets up the memory map?

No, there is no direct connection between processor mode and
and addresses.  There is a practical distinction between
(data/text) vs. stack "segments" though.

Half of the address space is reserved to the system and is
shared by all processes, ie. the system is in the virtual
address space of every single process on a Vax.  Conversely
when the system receives an interrupt/exception the address
map is set to the current process and consequently the system
is operating in the context of the current process, a major
feature which does not exist on any memory managed processor
that I'm intimately familiar with.

The half of the address space that is reserved to the current
process is split into two regions (program and control), the
program region as the name suggests usually holds your code
and data while the control region is used to hold the stack.
Each of these regions has a 30 bit virtual range and they grow
in opposite directions.  If the Vax had a two level paging
scheme there would be no real reason for making this region
distinction as it would become much cheaper to map a sparse
address space.  However as things stand there are separate page
tables for each of the regions, that map one (virtually) contiguous
chunk of each.  All this just so you don't have to have page tables
covering the "gap" between the program and control regions.

DEC could design a Vax with a multi-level paging scheme without
impacting user programs, even if memory management is described
in the "VAX Architecture Handbook" B-).  Can anyone that has the
"VAX Architecture Reference Manual" handy, tell me if it explicitly
defines the regions and the single level paging store?

			Bjorn R. Bjornsson
			alberta!bjorn