🚀 go-pugleaf

In article <37774@cornell.UUCP> huff@cs.cornell.edu (Richard Huff) writes:
>The simpler (and cleaner) way to solve this problem, is to provide a 64 
>bit virtual address space for the entire system, rather than a separate 
>32-bit address space for each process.  For example, consider HP-PA.  
>Each virtual address is composed of a 32 space id (sid) and a 32 bit 
>offset --- i.e., we have hardware imposed segmented addressing, but 
>without the aliasing problems of the Intel brand of segmentation.
>A "short pointer" access is when the user does not (directly) specify a 
>sid; instead, the top 2 bits of the address select one of 4 special sid 
>registers (sr4 through sr7).  A "long pointer" access is when the user 
>specifies one of 4 other space registers (sr0 through sr3) explicitly.  
>The user can change sr0 through sr4; changing sr5 through sr7 is a 
>privileged operation.  MPE XL sets sr4 to point to the program file's 
>sid, sr5 to point to stack/heap space, and sr6/sr7 point to OS sid's.

As I read this, the HP-PA does _not_ have 64 bit virtual addresses.
It has 32 bit addresses and segments.

There are several ways to tell the difference.  First, if the machine
had 64 bit virtual addresses, then I could place an array so that it
runs past the end of one segment, and into the next (logically
contiguous) segment.  A loop which went down this array would not
have to be coded differently, not at the high level, and not at the
machine code level. (It would be acceptable to have to do out-of-loop
things, like provide fault handlers.)

Second, if the machine had 64 bit virtual addresses, then a library
routine, passed an address, would not have to do a system call to
make the address usable. (Or have to worry about getting the sid
registers back in the original configuration.)

It's a good machine, but it would be a better machine if instructions
could actually compute and use 64 bit addresses.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science