Path: santra!tut!draken!kth!mcvax!uunet!lll-winken!csd4.milw.wisc.edu!dogie.macc.wisc.edu!uwvax!rutgers!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!hpcuhb!viggy
From: viggy@hpcuhb.HP.COM (Viggy Mokkarala)
Newsgroups: comp.arch
Subject: Re: Re: looking for >32-bit address space [and how will C handle it]
Message-ID: <3830007@hpcuhb.HP.COM>
Date: 20 Apr 89 22:18:24 GMT
References: <16568@winchester.mips.COM>
Organization: Hewlett Packard, Cupertino
Lines: 188


I will attempt to answer some of the questions that were raised about HPPA
during the course of discussion on this topic.

In article <16568@winchester.mips.COM> (John Mashey) writes:

(Discussion about address-space extension, and 64-bit address models removed.)

>The other interesting input that people might be able to give is what they
>really do on the earlier-mentioned machines that have segments.
>Can anybody say how the two HP OS's use them?  Can people talk about how
>RT PC's use them?  Do any 386 UNIXes use them?  How do they work in practice?
>Anyway, it would be nice to get real experience and data.
>-- 
>-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>

First a little about addressing in the Hewlett Packard Precision Architecture
and the way short and long pointers are specified.  Virtual memory is
structured as a set of address spaces specified by the concatenation of a space
identifier (which can be 16, 24, or 32 bits long) and an offset within the
space.  The space identifier portion of the virtual address comes from one of
the eight space registers.  During the virtual address computation, the offset
portion does NOT overflow into the space identifier portion to form the
effective virtual address.  In that sense, addressing in HPPA resembles a
segmentation style of addressing.  Within a space however, standard paging
techniques are applied.

One of the two operating systems that are available on HPPA machies is the HP
proprietary OS called MPE-XL.  The other, of course, is HP-UX - HP's version of
the Unix operating system.  The HP-UX kernel uses long pointers, but user
processes currently use only short pointers.  The MPE-XL operating system uses
long pointers extensively and user programs may access mapped files directly
through long pointers.

Long pointers (48-, 56-, or 64-bit) and short pointers (32-bit) in HPPA can be
specified as follows:

There is a two-bit field in the load and store instructions labeled the "s"
field.  If this field is a zero, then short pointers are specified.  If the
"s" field contains a non-zero value, long pointers are specified and the space
register corresponding to the value of the "s" field specifies a space register.

Short Pointers:

The high-order two bits of a base register select one of four space registers
(SRs 4 through 7, calculated as 4 plus the value contained in the
most-significant two bits of the base register) which contains the space ID of
the addressed virtual space.  The contents of the base register are added to
a signed dispacement or an index register to specify one of four quadrants
(the virtual byte offset address) of the addressed space as follows:

		_______________________________________
		|SS|       Virtual Byte Address       |-------------+
		_______________________________________             |
		 |                                                  |
		 |                                                  |
		 v                                                  |
	_____________________________________________________       |
	|               |                |                  |       |
	v               v                v                  v       |
      SR 4            SR 5             SR 6                SR 7     |
     _______         _______          _______             _______   |
     |SID a|         |SID b|          |SID c|             |SID d|   |
     _______         _______          _______             _______   |
	|               |                |                   |      |
	|               |                |                   |      |
	v               v                v                   v      |
     _______         _______          _______             _______ 0 |
     |     |         |/////|          |/////|             |/////|   |
     _______         _______          _______             _______ 1 |Gbyte
     |/////|         |     |          |/////|             |/////|   |
     _______         _______          _______             _______ 2 |Gbytes
     |/////|         |/////|          |     |             |/////|<--+
     _______         _______          _______             _______ 3  Gbytes
     |/////|         |/////|          |/////|             |     |
     _______         _______          _______             _______ 4  Gbytes

Long Pointers:

Long pointers specify a space register (SR 1 if the "s" field of the
instruction contain a 1 and so on) plus 32 bits of virtual byte offset address
within the space specified.  This virtual byte offset is the whole base
register plus a signed displacement or an index register, giving you the entire
4 Gbytes of offset within any space that is selected.

MPE XL Usage of the 64 Bit Virtual Address Space:

One of the fundamental benefits of MPE XL is the high file system performance
gained by the use of mapped files.  This is accomplished by assigning each
file an entire space (a unique value for the high-order 32 bits of the virtual
address).  The base of the file then has an offset of zero.  This provides a
very high-performance way of managing cached file data, because it allows the
file system cache to consume all unused memory and contend with other users
of memory on an equal basis.  The other obvious benefit of mapped files is
that a buffer translation/search mechanism is not needed, since this is
provided by the TLB.

MPE-XL Use of Short Pointers:

MPE-XL uses the short pointer virtual space as follows:

    -------------------------------------------------
    |    SR4    |    SR5    |    SR6    |    SR7    |    
    -------------------------------------------------
    |Code       |Process    |OS Global  |OS Global  |    
    |Program or |Data       |Data       |Data       |    
    |Library    |           |           |           |    
    -------------------------------------------------

On the 800/900 series, SR4 contains the current executable code (supported by
the common compilers and linker).  SR5 is changed for every context switch to
point to the process data (stack, global variables, heap, tables, etc.).  SR6
and SR7 remain constant for the life of the OS.

Each process is also assigned its own space and the 2nd quadrant (SR5) is used
for all process data structures.  

MPE-XL Summary:

Overall the main advantage of the 64 bit virtual address is the fact that all
virtual addresses are globally accessible and there is no need for address
aliasing or dynamically changing the translation structures depending on which
process is running (as in the VAX or IBM 370).  This allows a simple
implementation of mapped files, as well as a convenient means of inspecting
process-local data of the process not currently executing.

HPUX Usage of the 64 Bit Virtual Address Space:

Currently in HPUX, it is the operating system that knows about and uses long
pointer address space.  The user process model in Unix knows nothing about
long pointers and sees only the 32 bit short pointer address space currently
mapped by space registers 4 - 7.  Future systems might allow the use of a
larger address space when manipulating mapped files (see MPE-XL note above).
Some HP languages do support long pointers, but HPUX applications do not
take advantage of these features.  Several HP supplied pascal libraries shared
between the MPE-XL and HPUX products do use long pointers, however when
running under HPUX these long pointers resolve to an address in short pointer
space.

The HPUX operating system places each user process in a separate space 
(long virtual address).  Because of this we do not have to flush the cache or
TLB on a context switch.  Shared objects are mapped in via their long address
directly into the users' 32 bit space.  Long pointers allow us to share text or
data directly between users without having to resort to aliasing techniques
which are not easily supported on the HPPA architecture (because the
architecture allows virtually indexed caches).  Protection IDs (page access
keys) are used to control users' access to shared objects.

One challenge for the unix community is to determine how to support large user
mapped files (objects) whose cumulative size is greater than the short pointer
space available to the user process (typically 32 bits).  One approach could be
to access mapped data through a <object, offset> pair, or <object, segment,
offset> 3-tuple similar to the file system <fd, offset> tuple.

A user level library could be supplied which would determine the actual
location of the object in memory, and copy the data.  On a machine with a
smaller address space, this might require the library to remap a portion of its
address space to the <object, offset> being requested.  On machines like HPPA,
this may be a simple table look up, and space register insert.  The goal is to
determine an interface which will work effectively on machines with smaller
address spaces, but yet allow machines with large address spaces to exploit
their architecture.

In article <16932@winchester.mips.COM> (John Mashey) writes:

Quoting Shankar Unni (unni@hpda.hp.com)

>>Well, it's true that declaring a pointer the usual way yields a 32-bit
>>pointer (a short pointer), but it's possible to declare full 64-bit
>>pointers and manipulate them as such. Yes, the address space is segmented
>>into 4GB segments, so no single object can be larger than 4GB (32 bits).

>Can you say what the C declaration is, that yields a 64-bit pointer?
>-- 
>-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>

The way to declare a 64 bit pointer is to say:

	int ^i;

instead of 

	int *i;

____________________________________________________________________________

Viggy Mokkarala, Hewlett Packard Company, Cupertino, CA
viggy@hpda.hp.com