🚀 go-pugleaf

In article <8199@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU 
	(Donald Lindsay) writes:
>As I read this, the HP-PA does _not_ have 64 bit virtual addresses.
>It has 32 bit addresses and segments.

It has been pointed out to me that I am wrong. The HP-PA is better
than I thought.

>.. 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.)

System calls aren't necessary, because several of the space registers
are unprivileged.  Getting the registers back in their previous state
is now just another aspect of the normal register save/restore .

As a practical matter, I assume that library routines would come in
64-bit versions, and in optimized 32-bit versions.  This is "big model"
and "small model", but without some of the Intel pain.

>... 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.)

The HP_PA almost has this right.  A program can indeed increment a
64-bit pointer (by issuing two 32-bit instructions, I believe.)
However, if a carry occurs into the upper 32 bits, the space register
isn't automatically going to know about it. So, the program must set
the space register on every pass through the loop, violating one of
the criteria above.  (And also making expressions like 

	a = array[i-1] + array[i];

kinda clunky, since the compiler has to allow for boundary crossings.)

-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science