lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (02/28/90)
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
lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (03/01/90)
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