(Note: two sections herein: comments on 32/64 bits/POSIX, and the reply to the "why no non-priv access to freezing data") Dan writes: > I'm still looking forward to real usable 64-bit memory on MPE, too. Note Hmmm... you stopped looking years ago...maybe you forgot? > that although you can open a file long-mapped (with a 64-bit pointer), MPE > apparently limits you to a file size of 2 gigabytes. Doesn't sound like 64 4 GB...years ago. And, you're right: that's a 32-bit limit (well, a modern 32-bit limit, compared to POSIX 2GB 32-bit limit...difference between unsigned and signed 32-bit integers). The key difference between PA-RISC's 64-bit architecture and other newer ones is that there is no 64-bit integer arithmetic hardware. This means that in practice you are limited to having billion of separate address spaces, each of which is limited to 4GB. So, you have a total address space of 4GB * 4GB (16,000 terabytes bytes), but not as a single 64-bit flat address space. That's one of the reasons that MPE limits a file to 4GB. HP-UX, being POSIX oriented limits you to 2GB. Example of hardware limitation. Let's say you got MPE/iX (or HP-UX) to give you 8 GB of "contiguous" virtual address space, starting at $100.0. (I.e.: addresses $100.00000000 through $101.ffffffff) If you have $ffffffff in register R21, and $100 in Space Register SR1, and attempt to fetch byte $101.$00000001 by doing: LDB 2 (1, 21), 9 it won't work. You hoped that the arithmetic of adding 2 to unsigned $ffffffff would result in the space ID of $101 being used (because of the carry) and the offset of $1 (bottom 32 bits of result of $ffffffff + 2) ... but what happens is that the result of $ffffffff + 2 doesn't affect the space register, so the byte accessed is at $100.1. That's the limitation that PA-RISC 8000 architecture (announced a while back) addresses. (I seem to recall that that will have 96 bit virtual memory.) > POSIX's API allows you to access files or memory of any desired size, easily > beyond 2 gigabytes. See lseek(2), and keep in mind that off_t is > architecture specific just like size_t is. Been there, done that. I just realized that, according to Dan's arguments, I can claim that POSIX doesn't even support files bigger than 32KB! (If I happen to have an architecture where off_t is 16 bits!) In short, unless the POSIX "standard" says "off_t" *MUST* be at least 33 bits, then you cannot write a "POSIX compliant program" that is guaranteed to be able to use files > 2GB. A standard that says "off_t" may range from x bits to y bits on different architectures (where x < y) is actually less useful than one that says "off_t" must be x bits. Why? Portability is impaired. You can more easily write portable code if you *know* that the size of the types are fixed across various architectures. Ah, for int16, int32, int64 ... types that mean something! > POSIX was not so shortsighted as to not be able to see beyond 32 bits. No, but cross-eyed enough to screw up anyway! > >> Both methods given (the 'debug method' and the 'freeze' method) do not > >> address the need to *programatically* do memory locking from within an > >> application itself. Is there a way or isn't there a way to have an NM > >> program do this on MPE? > >Yes, PM required: > > Any non-priv modes? If not, any reason why? Yes, two reasons I can think of: 1) providing a non-priv method means documenting it ... which takes a lot of work, and testing ... for little payback. (It won't sell more machines, I hear the marketing people say) 2) hubris? ... the theory is that letting users freeze data into memory would defeat the efforts of the memory manager / dispatcher... which presumably knows better than the programmer. Personally, I feel that in some cases the programmer does know better! (and, in others, MPE knows better) -- Stan Sieler [log in to unmask] http://www.allegro.com/sieler.html